[ On Wednesday, July 9, 2003 at 04:54:18 (+0200), Matthias Buelow wrote: ]
quoted text
> Subject: Re: fsync performance hit on 1.6.1
>
> Greg A. Woods writes:
> 
> >What do _you_ mean by "multiplexed"?  And are you talking explicitly
> >about message queues in particular?
> 
> Yes, of course.

We already knew that we couldn't poll() on message queues, so what do
_you_ mean by "multiplexed"?

quoted text
> A feature?  Resources that don't get freed because a per-process
> reference count is missing?  Just imagine what the situation would
> be if files weren't closed when a process terminates (involuntarily).

Yes, a feature -- they are independent entities that can remain in place
between process invocations.  (just like files :-)

quoted text
> It's not an implementation bug if you don't know if the identifier
> you see in ipcs is still in use (and deleting it might crash the
> process using it) or if it's free (and thus could safely be ipcrm'd).

You can easily tell what process last used an IPC facility: "ipcs -p"

quoted text
> Of course a fully implemented, sensible, standardized API is
> preferrable in the long run.  I don't know the story of the SysV IPC
> stuff but it's very likely that it was a quick ad-hoc thing written
> without proper design in order to provide the necessary IPC mechanism
> for some specific software that needed to be written.

SysV IPC wasn't a "quick ad-hoc thing" as far as I can tell.  It is very
generic and was apparently designed to provide an integrated set of
generic IPC facilities that could be used safely and reliably in
production environments.  I once used SysV IPC to build some of the core
communications software in an application that was used to control
real-world railroad switches and signals.  I've used it in lots of other
kinds of applications too.

quoted text
>  It predates BSD
> sockets in any case

Hmmm... I don't know about that for sure...

quoted text
> (wasn't it already available in SysIII?)

Nope.  They call it SysV IPC for a reason....

(SCO back-ported it to an earlier version of XENIX, but did so badly and
with some nasty bugs.)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>