Add some documentation for CRT S3 Client#625
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #625 +/- ##
=======================================
Coverage 89.05% 89.05%
=======================================
Files 23 23
Lines 7748 7748
=======================================
Hits 6900 6900
Misses 848 848
🚀 New features to boost your workflow:
|
| #include <inttypes.h> | ||
| #include <math.h> | ||
|
|
||
| /* |
There was a problem hiding this comment.
we have a design doc folder that in the past we intended as a place to put detailed description kinda docs. does that belong there?
| * | ||
| * Threading model: | ||
| * | ||
| * All scheduling decisions run on a single event loop thread (process_work_event_loop), |
There was a problem hiding this comment.
important point here: the way scheduler works is when it kicks off it moves all the pending work into separate area, i.e. it captures the state of the world and no one else is supposed to touch that state. then it does all the scheduling work and updates global state after.
its totally possible that more work will arrive while schedule is running, but it will not be touched until next iteration of scheduler
| * Event loop groups: | ||
| * | ||
| * Bootstrap ELG (client_bootstrap->event_loop_group) drives networking. HTTP connections | ||
| * are pinned to loops in this group. One loop from this group is designated as the |
There was a problem hiding this comment.
pinned is a bit confusing in this case. you might want to expand on exactly what you mean
| * The task runs s_s3_client_process_work_task(), which calls the vtable's process_work, | ||
| * defaulting to s_s3_client_process_work_default(). All scheduling decisions happen there. | ||
| * | ||
| * schedule_process_work_synced() is called from: |
There was a problem hiding this comment.
i feel conflicted about mentioning specific function names in doc. will be really hard to keep in sync with actual code
| * | ||
| * A request moves through the pipeline as follows: | ||
| * meta_request->update() produces a request, which goes to s_acquire_mem_and_prepare_request() | ||
| * to reserve a buffer from the pool (may block if memory is full). Then vtable->prepare_request() |
There was a problem hiding this comment.
not block. it will just async wait until mem frees up
| * complete, it produces a CompleteMultipartUpload. When that finishes, update() returns | ||
| * work_remaining=false and the client removes the meta request. | ||
| * | ||
| * For GetObject, the state machine first sends a HeadObject or a ranged GET for part 1 to |
There was a problem hiding this comment.
its a lot more complicated than that. there is a doc on that in design folder
3 participants
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.