On Sat, Jan 28, 2017 at 1:22 AM, Justin Cinkelj <justin.cink...@gmail.com> wrote:
> One thing confuses me - how/why the original commit worked for Nadav? > Again some compiler difference (gcc 4.8...) > To be honest, I was surprised that the "magic number" was 3, I'm not even sure who holds all these 3 copies. So I guess it's not surprising, it was actually wrong. I'll rethink this. > > I see one problem with concept of forgetting all info about old apps. In > Linux, I'm used to: > 1. start app > 2. shell waits until app finishes > 3. exit code (echo $?) shows, if it finished normally or with error. > > I sent some RFC patch(s) to implement "waits until app finishes". > There is app identified by thread ID running its main() function. > > But exit/return code of app will be impossible to retrieve if we just > forget everything about terminated apps. > All the "osv::application" stuff in OSv is making me sad. It's a pile of ad-hoc fixes to small problems that more and more reproduce other layers that we already have, sometimes for the third time - after many similar issues of reference-counting, detaching, etc., have already been solved in lower levels (sched::thread, elf::object, etc.). Moreover, the current osv::application::run_background code still has bugs which we already solved in other code, namely - the issue that the main thread hasn't started yet when we return, which makes it problematic to test if the application has terminated - or haven't even started! If you remember, we already solved the same issue in osv_execve() and I will be very sad if I need to solve it again in osv::application::run_background(), and ad-hoc API that nobody actully uses. In case any reader is not familiar with how POSIX does what you want to do (for child processes, not threads) here's a quick overview: 1. A child processes that exits does not go away, but rather remains a "zombie" process. 2. A zombie process only takes minimal resources (process structure), no longer has stack and other stuff (see our issue #844). 3. A parent can use, at a time it chooses wait(2) and friends, to see which children have died. wait() returning a child deletes its zombie. 4. If a parent wants to know immediate that one of its children died (not only when it calls wait(2)), it can catch the SIGCHLD signal. I think we can do something similar (at least to 1-3). Instead of my previous patch, do something like this: 1. httpserver uses osv::run_background() to run the background operation, and receives an osv::application object. 2. httpserver holds a map of numeric id to pair of weak_ptr<osv::application> (?) and another map for exit code, giving a new integer id to each application (these will not be related to actual process ID). 3. A new function like osv::application::join_terminated() will return an array of already terminated apps. The httpserver will save their exit codes and unreference the actual application so it can be destructed. Of course we need to recognize terminated applications correctly :-( 4. A new rest API will query the exit code of an application with a given ID. 5. Note we can't ever delete the exit code, even after we return it, because it is always possible the client didn't receive the response and may try the same request again... Does this sound reasonable? If you didn't need the actual exit code - just to know if the application is still running, things would be slightly simpler because we just need to maintain a list of still-running apps and their ids, and not remember anything about old apps. > 3. is then not possible any more. TODO - fill issue. > > We could save such "interesting details" in additional data structure > (thread ID of main(), and its exit code). > The "is app finished" is true, if TID is in the list. > And exit code is there too. > > > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
