Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1288

Re: async I/O

Cross-posted to 2 groups.

Show all headers | View raw

On 2/5/2012 5:52 PM, Mark wrote:
> Hello,
>
> (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.

     You say "a" pipe; is that really what you mean?  If A writes to
one pipe and both B and C read from that same pipe, there's just no
telling which process will read which bytes.

     Maybe it's just a slip of the keyboard and you're really using
two pipes (one between A/B and another between A/C).  Worth noting,
though, just in case.

> 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)?

     If you meant "C" instead of the final "A", then yes: The fact
that A writes to the A/B pipe before writing to the A/C pipe does
not guarantee that B reads its data before C does.  B might be busy
doing something else, B might be blocked on a page fault, or maybe
the scheduler has decided B's been too greedy and it's time to give
C a crack at the CPU.  Even if both B and C are blocked in the kernel
waiting for data to arrive on their respective pipes, it's not certain
B will run before C does.

> I understand there might be not enough information to make any assumptions,
> but what are the basic approaches to debug async I/O and situations similar
> to mine?

     You're right about the "not enough information" part ;-(

     One thing I can suggest that might let you gather data with less
of a "probe effect" than setting breakpoints is to add some tracing
to each of A,B,C.  Have each program make records of important events
like "sending 42 bytes to B" or "received 28 bytes from A", and mark
each with the finest-grained time-stamp possible.  Don't write these
trace records to a log file (not yet, anyhow), because the extra I/O
may be enough to disturb the timings; just dump them in circular
buffers in memory.  You can write them out when things quiet down:
At program exit, maybe, or when you send SIGUSR1 to a program.  By
interleaving the three logs and studying the actual sequence of events,
you may gain more insight into what's going on.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

async I/O "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-02-05 17:52 -0500
  Re: async I/O jt@toerring.de (Jens Thoms Toerring) - 2012-02-06 01:18 +0000
    Re: async I/O "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-02-05 22:43 -0500
  Re: async I/O Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-06 00:38 -0500
  Re: async I/O scott@slp53.sl.home (Scott Lurndal) - 2012-02-06 16:11 +0000

csiph-web