On Sun, Nov 19, 2000 at 07:24:16PM +0900, GOTO Masanori wrote: > At Mon, 13 Nov 2000 11:13:19 -0500, > Jakub Jelinek wrote: > > ago were done in the kernel, POSIX message queue passing is not doable in > > userland without kernel help either (I have a message queue filesystem > > kernel patch for this, but it is a 2.5 thing). > > Interesting. Is yours ready for? > (I'm also working with it. I agree it's for 2.5) Below is my preliminary version from Sep, 16th if you're interested. I haven't had time for it since then, so it most probably will not apply cleanly to current kernel. Things still to do: - clean it up - implement poll on message queues - handle __SI_RT in architectural copy_siginfo_to_user routines - test much more than I have done so far - fix mq_notify - see below - avoid doing linear searches - see below Message queues are presented as a new filesystem, mounted usually on /dev/msg. The objects in that filesystems are fifos with special MQ semantics. One can use normal open/read/write on fifos in /dev/msg, which means mq_open with mq_attr NULL, mq_receive which does not tell the priority and mq_send with default priority. Then there are a few ioctls which allow to open with special queue attributes, send with priority and receive so that you get priority back, etc. Things I'm not sure about is mq_notify, because it states the signal should be sent to the process (ie. I'd think it is tgid, not pid in 2.4.0-test8, but then I don't know which close/exit should cause the notification registration to be freed). Also, I wonder how many pending messages typical message queues have pending, if not too many, then the current linear search is fine, otherwise I should put the messages into some heap which would allow O(1) mq_receive. If you find any races/problems, please let me know. I've coded mqueue.h public glibc userland header and mqueue.c which has hacks on top and then basically what could end up in glibc's mq_*.c (after shm_open.c code for locating mount points is copied in). Jakub