Subject: kern/3537: Idea for SysV IPC Messages improvement
To: None <email@example.com>
From: Ty Sarna <firstname.lastname@example.org>
Date: 04/25/1997 16:40:39
>Synopsis: Idea for SysV IPC Messages improvement
>Responsible: kern-bug-people (Kernel Bug People)
>Arrival-Date: Fri Apr 25 13:50:01 1997
>Originator: Ty Sarna
Endicor Technologies, Inc., San Antonio, Texas
System: NetBSD iocane.endicor.com 1.2D-970415 NetBSD 1.2D-970415 (IOCANE) #4: Tue Apr 15 11:56:58 CDT 1997 email@example.com:/usr/src/sys/arch/i386/compile/IOCANE i386
SysV messages look appealing to the programmer, until s/he
finds out there is no way to wait on both a message queue and
file events without busy-waiting.
Try to find a way to do that.
If I recall, AIX added yet another syscall that is select()
plus additional argument(s) for message queues. This is kind of
It just occurred to me, while looking at how SIGIO is
implemented, that a similar idea could be implemented for
message queues. One could specify, via msgctl() probably, a
process or process group and a signal number to be delivered
when a message is enqueued. Then one could install a signal
handler for that signal that either handles the message itself,
or sets a flag. If the process was select()ing at the time,
it'd fail with EINTR and the event loop can check to see if
the signal handler recorded any messages arriving,
and if so handle them.
While it doesn't fix the basic fault of SysV ipc (not file
descriptor based), it does provide a way to wait on files and
msgqueues sanely without adding another syscall or redisigning
SysV messages in an incompatible way.
Note my idea above that the signal should be specifiable... that
way we don't use up any more signals (we're already at 32), and
give the programmer some choice. In normal use, the programmer
should probably use SIGIO (used as the default?) or SIGUSR.
I don't have any particular need for this functionality at the
moment but as it's a long-standing problem I thought I'd better
send-pr the idea before I forget it.
On a related note, it'd be cute if the signal sent could have
the message queue ID (or fd in the case of SIGIO for O_ASYNC
fd's) sent as the Code argument to the signal handler, but this
looks nigh-on-impossible with the existing code (for the
fd/O_ASYNC case at least -- I haven't looked at the SysV msg
implementation in detail).