Gary Bressler would like Owners Override to review this change.
[dso_runner] Initial skeleton
Basic core functionality that supports sync and async components that
share an address space. This changelist includes:
- "synchronous" components - components that get a dedicated
thread
- "async" components - components that run in a shared Fuchsia Driver
Framework thread pool, much like components in driver runner.
- Component lifecycle support for start/stop/exit
- Unit tests
- Simple example (//examples/components/dso)
Not included/upcoming in future changes:
- Namespacing support for either sync or async components. For now they
share the same global namespace/fdio/etc. as the runner process.
- Running the components in a separate address space for the runner.
This currently isn't too important since all the DSO components share
the same address space, but it could become relevant when/if we
support multiple "containers".
- Integration test - I want to have this but I think it makes sense to
land the namespacing support first.
- Routing of dso_runner in the component topology
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Owners-Override for //src/lib/dso which is a new directory so it has no OWNERS and its parent also has no OWNERS
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
unsafe extern "C" {Gary Bressleryou could actually declare these functions safe since it seems like they probably are always safe to call. You'd do that by putting `safe` in front of the `fn` declarations. This is in tests so not super important to document why, but it would probably still be a good idea to.
Megan BattyTIL about `safe`, my IDE doesn't even know about it :-)
it is very very new and but I'm personally very happy it exists now :)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gary BresslerThere's a pretty hefty amount of unsafe in this change and I'd really like to make sure it's well documented, so I did an unsafe review of this change. The general theme though is:
- unsafe blocks should be as short as possible
- unsafe comments on unsafe blocks should explain why the body doesn't break the caller
- unsafe doc comments on functions should explain how to hold the function safely (focusing on things that affect rust's memory model)
- and the two should mirror each other.
- if a C function in an `extern "C"` block is always safe to call you can mark it safe and put a comment on it explaining why that is.
There's an android doc explaining pretty good best practices for this I can link you to if you want.
Megan BattyThanks for the review and best practice tips for unsafe. BTW ome of the code and comments were copied from the `driver-host` codebase so you may want to check those as well.
yeah I thought that might be the case. I definitely think we should revisit some of this in driver-host as well.
For owners-override, please create a CL that just has empty directories with OWNERS files.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
For owners-override, please create a CL that just has empty directories with OWNERS files.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Gary Bressler removed Owners Override and Adam Barth from reviewers of this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |