>Number:         3537
>Category:       kern
>Synopsis:       Idea for SysV IPC Messages improvement
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 25 13:50:01 1997
>Last-Modified:
>Originator:     Ty Sarna
>Organization:
	Endicor Technologies, Inc., San Antonio, Texas
>Release:        any
>Environment:
System: NetBSD iocane.endicor.com 1.2D-970415 NetBSD 1.2D-970415 (IOCANE) #4: Tue Apr 15 11:56:58 CDT 1997 tsarna@iocane.endicor.com:/usr/src/sys/arch/i386/compile/IOCANE i386


>Description:
	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.
>How-To-Repeat:
	Try to find a way to do that.
>Fix:
	If I recall, AIX added yet another syscall that is select()
	plus additional argument(s) for message queues. This is kind of
	icky.

	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[12].

	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).
>Audit-Trail:
>Unformatted: