Hi,

Ulrich Drepper preferred a simpler (from user space point of view) 
SIGEV_THREAD implementation:

SIGEV_THREAD means that a notification function should be called in the 
context of a new thread. The new thread is created by glibc in user 
space, thus the problem for the kernel is registering the notification 
and then delivering the event to user space.

Current approach:
mq_notify(SIGEV_THREAD) creates (and returns) a new file descriptor. 
User space reads from the fd. If the event happens, then the kernel 
changes the state of the created fd. User spaces notices that through 
read(2) and calls the notification function.

Problem:
- high resource usage: one fd for each pending notification.
- complex user space.

New proposal:
mq_notify(SIGEV_THREAD) receives two additional parameters:
- a 16-byte cookie.
- a file descriptor of a special notify file. The notify file is similar 
to a pipe. The main difference is that writing to it mustn't block, 
therefore the buffer handling differs.
If the event happens, then the kernel "writes" the cookie to the notify 
file.
User space reads the cookie and calls the notification function.

Problems:
- More complexity in kernel.
- How should the notify fd be created? Right now it's mq_notify with 
magic parameters, probably a char device in /dev is the better approach.

What do you think? The first approach is in Andrew's 2.6.4-rc1-mm2 
kernel, a patch that implements a notify file is attached.
I think that the added complexity is not worth the effort if the notify 
fd is only used for posix message queues. Are there other users that 
could use the notify file? How is SIGEV_THREAD implemented for aio and 
timers?

--
    Manfred