diff options
| author | Kimplul <kimi.h.kuparinen@gmail.com> | 2022-09-23 00:43:40 +0300 |
|---|---|---|
| committer | Kimplul <kimi.h.kuparinen@gmail.com> | 2022-09-23 00:43:40 +0300 |
| commit | 12bfd21818b7a90887dd4c6a92817b791fdb7600 (patch) | |
| tree | cf77d225d0c0e5304d301dc5de4cfe6445171d26 /include/apos/initrd.h | |
| parent | ae3905ebeb415e12667777463e36df6e00ca992c (diff) | |
| download | kmi-12bfd21818b7a90887dd4c6a92817b791fdb7600.tar.gz kmi-12bfd21818b7a90887dd4c6a92817b791fdb7600.zip | |
remove user data from sys_ipc_notify
+ Multiple notify signals at the same time, or queued ones waiting for
ipc_req/fwd to finish would require a notify stack of some kind, which
is maybe too complex for my liking. Not impossible by any means, but I
want to keep things simple.
Let's say a client wants the server to do some async operation. First,
the client calls ipc_req to inform the server that it would like the
operation to be done. The server sets this task in some work queue or
whatever, and returns to the client as quickly as possible. Later on,
when the task is finished, the server does a ipc_req to the client,
with data about what was just finished. The client is responsible for
noting this data down somewhere, either reacting to the operation
directly in the callback, or calling ipc_notify to the thread that
requested the operation. Other possible notifications at the same time
should be handled at the same time, whichever way the client wants to
handle them.
Note that ipc_notify triggers only when the thread it targets is in
its base state, i.e. not doing an ipc_req. This makes things a bit
easier.
Diffstat (limited to 'include/apos/initrd.h')
0 files changed, 0 insertions, 0 deletions
