Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!not-for-mail From: jt@toerring.de (Jens Thoms Toerring) Newsgroups: comp.unix.programmer,comp.programming Subject: Re: async I/O Date: 6 Feb 2012 01:18:10 GMT Organization: Freie Universitaet Berlin Lines: 63 Message-ID: <9p8o2iFub5U1@mid.uni-berlin.de> References: X-Trace: news.uni-berlin.de 6pxs7W5y4Rh3OCuPBV7LQw39IWNBQlYHDY5n6+BNiFxwnq X-Orig-Path: not-for-mail User-Agent: tin/1.9.3-20080506 ("Dalintober") (UNIX) (Linux/2.6.30-1-amd64 (x86_64)) Xref: x330-a1.tempe.blueboxinc.net comp.unix.programmer:2017 comp.programming:1285 In comp.unix.programmer Mark wrote: > (I've faced quite a complex piece of software using asynchrounous messaging > and am having a tricky bug, which I believe is relevant to async I/O, so I'd > like to clarify some concepts). > There are three processes, A,B and C, and A sends control messages to B & C > through a unix pipe. Now what happens is: process A sends a command to B, if > network link is not up, B sends command to C('link up') and C later confirms > to A that it's done, so B can change its state machine state. Also at some > moment process A sends 'link up' command to C. However state machine in B > never changes, although when I debug with GDB step-by-step, it functions > correctly (timings issue etc.?). > Also, another observation - I set breakpoints in both processes B and C, > then execute A -- every time I start debug session, either B or C will be > the first to receive the message, so there is no guarantee that B or C is > always the first to get the message (I don't understand why). > Is it possible that asynchronous messages don't deliver in order, e.g. A > first sends to B and then to C - can the B receive its message first and A > gets its message second (first or second in terms of timeline)? I'm a bit puzzled what you mean by "asynchrounous messaging" and "control messages" - my applogies if I miss the core of your pro- blem completely. From what else you write I get the impression that you have a number of pipes A -> B A -> C B -> C C -> A Now, if you expect that when you write to the A->B pipe and then to the A->C pipe that this would guarantee that B will read on its pipe first before C reads on its then you're ma- king wrong assumptions. The order in which processes are scheduled to run by the operating system should be considered to be completely random (and the processes A, B and C may even run in parallel on machines with more than one processor!) There is nothing that would ensure that process B will be run before process C just because your process A first wrote to a pipe to B and only then to a pipe to C. The operating system schedules processes for running by a lot of different criteria and you can never, ever rely on any certain order (well, un- less you have read und understood the kernel sources in every relevant detail and you are prepared to adjust your program for every release of the kernel in existence;-) So, if you want process B to read data from a pipe before process C you must introduce some mechanism that makes sure that this is what's going to happen. Just writing to a pipe to B before writing to a pipe to C does not. One way would be to have B send back an acknowledgment when it has finished reading its data (e.g. via another pipe in the opposite direction or a signal) and only then start sending data to C. Only something like that can guarantee that C won't start to read before B is done. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de