Very Computer

Does anyone know the function "select( )" is not support UNIX System V
IPC's "Message Queue" ? When I pass message queue ID into this function, it
always return -1. Anyone one can tell me the answer ?

Quote:> Does anyone know the function "select( )" is not support UNIX System V
> IPC's "Message Queue" ? When I pass message queue ID into this function, it
> always return -1. Anyone one can tell me the answer ?

While a lot of UNIX APIs follow the "all is a file" paradigm,
the SYSV IPC objects are a bit alien.

Hope this helps
Michael

--
Michael Marxmeier           Marxmeier Software Entwicklung GmbH

Voice : +49 202 2431440     42119 Wuppertal, Germany

The System V IPC package implements (Semaphores, message queues
and shared memory). This package provides some excellent communications
mechanisms on a single computer. It is NOT network based.

As internetworking of computers became popular, the system V branch of
Unix
added a network interface called Streams. This package performs similar
 functions as the BSD network package(also frequently called sockets).
Many people preferred the socket interface and as a result it was also
ported to System V first as ass on packages and then eventually as
part of the Merged System V/BSD.

So, what to do about select() and message queues?

Well it's more portable to simple develop to the socket interface. Sockets
are also quite usable on a single processor, implementations are
reliable and performance is good. The advantage to using sockets in
this case are that porting to BSD is easier and making your app network
based is also easier. The socket interface also exists on many other
systems(i.e. Novell Netware, MS Windows/95/NT, VMS ...).

If for some reason you must use IPC message queues, then try not to
mix the implementation with sockets.

If you must use both, then you will have to use the IPC routines to get
IPC messages and the select() routine to get socket data. You will
need to decide which of the two input streams will get precedence.
The one which does will become the interface to "block" on. Call that
interface and either block on it, or set a short timeout. You would
then have to determine some kind of input handling "scheduling"
i.e. round robin, priority ... This can become quite complicated
and will determine the character of your application.

It's best to pick one or the other, preferably sockets. If you have
the option, you may also want to look at RPC/XDR which makes
some things easier to implement.

Hope this helps.

Oh, ceck out Unix Network Programming, by Stevens.

"The select subroutine checks the specified file descriptor and message
queues to see if they are ready for reading (receiving) or writing
(sending), or if they have an exception condition pending."

I am told this feature is somewhat unique to AIX, however...

Loren Cain

 >> While a lot of UNIX APIs follow the "all is a file" paradigm,
 >> the SYSV IPC objects are a bit alien.

 GMacdon680> The select() system call is part of the Berkeley network
 GMacdon680> communication package. It was nicely generalized on top
 GMacdon680> of the existing file descriptor interface allowing all
 GMacdon680> input streams( pipes, files, network I/O, local I/O) to
 GMacdon680> be nicely multiplexed and manipulated.

 GMacdon680> The System V IPC package implements (Semaphores, message
 GMacdon680> queues and shared memory). This package provides some
 GMacdon680> excellent communications mechanisms on a single
 GMacdon680> computer. It is NOT network based.

Whether it is network based is irrelevent - *files* aren't network based
either. The designer of SysV IPC managed to break one of Unix's best
consistency features - the ability to handle lots of different types of
things through a common interface (file descriptors).

 [...]

 GMacdon680> So, what to do about select() and message queues?

There is one Unix flavour (AIX) that actually allows you to pass message
queues to select(), but that feature is a horrible hack (and has zero
portability).

In general, though, the answer usually is to design your app so that any
given process only ever waits for one kind of thing.

--

"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam

A good way to get around this is this:

fork(2) off a process to perform a msgrcv(2) for each queue in which
you are interested.  When a child has received a message, have it
write the message across a pipe (created with pipe(2)) to the parent.
Then the parent process will essentially be able to select(2) on
message queues.

Dave

--