Re: User vs. Kernel (was: To be smug, or not to be smug, that is , the question)

doctor@fruitbat.org
Wed, 27 Jan 1999 16:14:55 -0800 (PST)

Richard Gooch said ...
> doctor@fruitbat.org writes:
> > Richard Gooch said ...
> > > Alan Cox writes:
> > > > > >> entirely from userland.
> > > > > > sure it was implemented - i've used it in (apparently small) project.
> > > > > In userland, you can't support message queues in select() like AIX can.
> > > > Im amazed people stil use them, they are a classic example of retrofitting
> > > > somethng un-needed onto unix without the people at the time thinking what
> > > > they were doing.
> > > Agreed! What the hell is wrong with a pipe/socketpair anyway? It fits
> > > right in there in the everything-is-a-file model. Message queues don't.
> > So? What's wrong with that? Shared memory isn't a file.
> > Semaphores aren't files? Neither are message queues and a whole
> > slew of other things that aren't files. They all have their uses.
> > Not everthing has to be a file. I've done a number of small
> > projects where we used message queues specifically because of the
> > message typing attribute. What's your problem?
>
> Smeaphores and shared memory provide very different conceptually
> different services from pipes. Message queues, however, provide the
> same conceptual service as pipes. So now we have duplication of

Only in so far as they provide a data transport. With pipes/socketpairs
you have to have a destination to connect to. Not so for Message Queues.
It provides a means of sending anonymous data out to a spool where anyone
may pull it at their convenience (ie: the received doesn't have to be
active when the sender is). The typing attribute gives the programmer a
way of discrete message designation. There are many uses for this.

> functionality, with the disadvantage that sending a message via a
> message queue is limited to the same machine (yes, I'm ignoring DIPC
> and such: they open up another can of worms). Sending a message via a
> pipe (i.e. write()ing to a FD) is not limited to the same machine
> (just call connect() instead of socketpair()).

Oh, please. Not more of "It's the 'Net, Stupid". That rates right up
there with people thinking the Web *is* the 'Net (which is balogne). If
the facility had been intended to be distributed, it would have been
designed as such.

> Anyway, I don't have a problem with message queues in the sense that I
> think they should be removed or anything like that. I just think that
> supporting them via select()/poll() is pointless. If you want
> multiplexing of message queues, use pipes instead.

Now, here I happen to agree. AIX implemented them as a convenient way of
waiting on FDs and msgqueues (which in AIX were distributed). That being
said, I only recall one program actually using that feature (one I wrote).

> Frankly, I'd like to see SysV message queues implemented in libc on
> top of pipes. Once shmfs is in the kernel, I'd like to see the SysV
> shared memory support ripped out of the kernel and put into user space
> too. It's good enough for POSIX SHM.

As long as the interface doesn't change and it's at least as fast and
stable as the kernel version, it'd be OK with me. But, that's shared
memory, not message queues ;-)

-- 
Peter A. Castro (doctor@fruitbat.org) or (pcastro@us.oracle.com)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/