#83 closed enhancement (fixed)
Pass task exit code
Reported by: | Martin Decky | Owned by: | Jiri Svoboda |
---|---|---|---|
Priority: | major | Milestone: | 0.4.1 |
Component: | helenos/lib/c | Version: | mainline |
Keywords: | Cc: | ||
Blocker for: | Depends on: | ||
See also: |
Description
It is possible to wait on a task exit. But the task exit code gets lost. Change the kernel, libc and ns to store and pass the task exit code to the task which is waiting.
Change History (5)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
Owner: | set to |
---|---|
Status: | new → accepted |
comment:3 by , 15 years ago
As of r4617 this works. The only 'but' here is that NS should be notified of the task ID of the task on a particular phone by the loader, rather than when passing the return value. This would prevent task ID spoofing by user programs.
The interface should be improved to get rid of races and zombies. Also it could be improved to differentiate between different events on the task (exited without returning a value, exited gracefully returning a value…)
Also it is not clear whether the kernel notifications on task creation/termination are very useful as they can be supplanted by the requests sent by the task to the NS for almost every purpose. (When the task dies the NS receives an IPC_M_PHONE_HUNGUP).
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
I changed NS from using kernel notifications to using IPC messages for determining when a task has started and finished. As the loader makes sure NS knows about its existence before doing anything else, this means NS knows about the task before task_spawn() returns. Thus task_wait() can fail immediately if there is no task with the given ID. Unlike with the kernel notifications, it cannot happen that NS would not know about the ID when we call task_wait().
The only thing that remains to be solved are zombies.
comment:5 by , 15 years ago
Milestone: | 0.5.0 → 0.4.1 |
---|
I would prefer a purely user-space solution (this would be consistent with how command-line arguments are passed). I am still toying around with the idea that a server could return a value as soon as it goes up, which would be useful for synchronization.