multiplexing
in [Unix Programming]
|
Prev: How to get IP address from C application
Next: Changing the style/color of output text in a Command Line program
From: Bill Cunningham on 22 May 2010 14:59 "Scott Lurndal" <scott(a)slp53.sl.home> wrote in message news:b2VJn.216743$XD2.153664(a)news.usenetserver.com... http://www.opengroup.org/onlinepubs/000095399/basedefs/fcntl.h.html > > shows O_SYNC, O_DSYNC and O_RSYNC, but no O_ASYNC. Maybe it wasn't fcntl. I've checked poll() and select() too and they don't have those arguments. Maybe I was thinking of O_SYNC. My mistake. Bill
From: Alan Curry on 22 May 2010 18:05 In article <87r5l5hrp0.fsf(a)fever.mssgmbh.com>, Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: >"Bill Cunningham" <nospam(a)nspam.invalid> writes: >> With client sockets, and networking in general what is the difference in >> IO multiplexing and asynchronous multiplexing? Is this for DGRAM and STREAM >> sockets? > >What is 'asynchronous multiplexing' supposed to refer to? There's not much context to go on, but this is a possibility: Multiplexing = handling multiple jobs (e.g. the servicing of requests from multiple clients) simultaneously. Synchronous multiplexing = in a single thread of execution, using an event loop which checks all of the running jobs, and does some work (e.g. a read or a write) on whichever ones are ready. The big select (or poll) loop. Asynchronous multiplexing = spawning a process for each job. In the synchronous method, if a data structure is accessed by more than one job, the event loop naturally serializes the accesses. The start of one event handler is synchronized with the end of another event handler. In the asynchronous method, you either don't have any shared data structures, or you have to protect them against multiple simultaneous access with some kind of lock since there's nothing synchronizing the events. inetd.conf uses the "wait" keyword for daemons that will do synchronous multiplexing, and "nowait" for asynchronous. In its documentation, they are called "single-threaded" and "multi-threaded", respectively. A rare remnant of a time when people understood that "multi-threaded" doesn't actually mean "without memory protection". -- Alan Curry
From: Rainer Weikusat on 23 May 2010 04:54 "Bill Cunningham" <nospam(a)nspam.invalid> writes: > "Scott Lurndal" <scott(a)slp53.sl.home> wrote in message > news:b2VJn.216743$XD2.153664(a)news.usenetserver.com... > > http://www.opengroup.org/onlinepubs/000095399/basedefs/fcntl.h.html >> >> shows O_SYNC, O_DSYNC and O_RSYNC, but no O_ASYNC. > > Maybe it wasn't fcntl. I've checked poll() and select() too and they > don't have those arguments. Maybe I was thinking of O_SYNC. My mistake. fcntl possibly does have O_ASYNC. This is a BSD-feature which is also supported by Linux and it is (also) called 'asynchronous I/O', although 'signal-driven I/O' was a better description. The way this works is that a signal is sent to the process when new data is available for some descriptor or when an output operation has been completed (and hence, the next one could be started without blocking the process). On Linux, it is additionally possible to assign specific signals (including realtime signals) to different descriptors and (when using realtime signals) the kernel can pass the number of the descriptor a particular I/O-signal is supposed to refer to the process which requested the notification. This implies that RT signals can be used to enable a single thread of execution to serve multiple TCP connections (commonly called 'I/O multiplexing') in a more scalable way than with any of the traditional interfaces (select and poll). But there is no 'asynchronous multiplexing' here (this combination of terms seems pretty absurd to me but I am not a native speaker), just the I/O-signals are generated asynchronously, as seen from the perspective of the thread of execution handling them.
From: Bill Cunningham on 23 May 2010 12:32
"Rainer Weikusat" <rweikusat(a)mssgmbh.com> wrote in message news:87hblzj8vn.fsf(a)fever.mssgmbh.com... > fcntl possibly does have O_ASYNC. This is a BSD-feature which is also > supported by Linux and it is (also) called 'asynchronous I/O', > although 'signal-driven I/O' was a better description. them. [snip] Linux is what I'm running. Bill |