b167307526
After load_image() the child thread is suspended and the parent is expected to resume it later. However, it is possible that the parent attempts to resume its child after it has been notified that the image had been loaded but before the child managed to suspend itself. In such case the child would suspends itself after that wake up attempt and, consequently will not be ever resumed. To mitigate that problem flag Thread::going_to_suspend has been added which helps synchronizing thread suspension and continuation in a similar way that "traditional" thread blocking is performed. This means that the child should behave in a following manner: set its going_to_suspend flag, notify the parent (i.e. any thread that may want to resume it), acquire its scheduler_lock and suspend itself if the going_to_suspend flag is set. The parent should follow pattern: clear going_to_suspend flag of the thread that is about to be resumed, acquire that thread scheduler_lock and enqueue it in a run queue if it is suspended. Thanks Oliver for reporting the bug and identifying what causes it. |
||
---|---|---|
.. | ||
app | ||
audio | ||
binary_compatibility | ||
bluetooth | ||
debug | ||
device | ||
drivers | ||
file_systems | ||
firewire | ||
fs_shell | ||
graphics | ||
index_server | ||
input | ||
interface | ||
kernel | ||
libroot | ||
locale | ||
media | ||
midi | ||
mount | ||
net | ||
notification | ||
package | ||
runtime_loader | ||
screen_saver | ||
shared | ||
storage | ||
support | ||
syslog_daemon | ||
system | ||
textencoding | ||
tracker | ||
usb_vision | ||
userlandfs | ||
virtio | ||
vmdk |