I'm thinking again about this. Why wouldn't it be possible to make functions using SIGEV_THREAD (such as timer_settime) create a pthread behind the scenes (only the first time a SIGEV_THREAD is setup)? The underlying watchdog would go to a handler that posts a semaphore/condition variable that the helper thread is waiting on. When this thread unblocks, it calls the user handler directly.
The thread would be created per-process in KERNEL mode, so that shouldn't be a problem (inside same address space as user handler). I suspect the unblocking of the thread should also be possible in multi-process somehow (named semaphore?). This is essentially what I'm doing myself around a call to timer_settime. Best, Matias On Wed, Jan 27, 2021, at 15:26, Gregory Nutt wrote: > > > Perhaps you could use a pool of application threads as is done with > > the kernel threads for the low-priority work queue. So you could have > > a small number of threads that service all tasks. When a user-space > > thread is needed, it could be removed from the pool and be assigned to > > the task to run the event. When the event processing completes, the > > thread returned to the pool until it is again needed. Tasks could > > wait for availability if there are no available threads in the pool. > Nevermind! This would not work in KERNEL mode. In that case, each task > (now better called processes) have there own separate protected address > enviroments and threads could never be shared across processes. It > would work fine in FLAT and PROTECTED modes where all tasks share the > same address space. >
