Re: other Solaris-related problems

[Yo Ric Dude <ericmit ix netcom com>]

Raja R Harinath wrote:

[snip description of esd network code problem]

> There's a very good chance of this happening since the daemon uses a
> non-blocking read to get the sample name, and doesn't check for
> EWOULDBLOCK/EAGAIN errors.
> 
> The fix is something like the ESD_NEED_VALIDATION stuff.  Protocols
> that have parameters (i.e., have ESD_READ_BIN/ESD_READ_INT in their
> protocol handlers) should introduce an additional state
> ESD_NEED_BIN_PARAMETER, or ESD_NEED_INT_PARAMETER, which then passes
> on that parameter to the handler.
> 
> The general point in programming `esound' is: don't put `read's in
> arbitrary places.
> 
> Whenever you need a read, you'll have to break up the code into two
> parts, and replace the read with a state transition.  This is
> unnatural, and inside out, but it is endemic to the mechanism used in
> esound -- non-blocking reads + single blocking select.
> 
> To repeat the point in a different way: do a read only when you know
> that read will succeed => the read should happen after the select says
> it can happen.  You shouldn't put many selects in different places;
> there must be on single select blocking on a whole lot of things =>
> you have to program inside out.

I've been reading the Steven's network programming bible, and some 
of this is actually sinking in and making sense.  One option I was 
considering was converting ESD_NEED_VALIDATION to something better 
described by SD_NEED_MORE_PARAMETERS, and filling a buffer (added 
to the client_t structure) with binary data up to the amount 
required for each individual request.  After all the data is in, the 
protocol handler would then be dispatched to process the request, 
and pick out the values it needs from the buffer.  

How does that sound?  The current code was a gross 11th hour hack 
to Just Get It Running (tm), and in bad need of fixing.

> There's no escaping it.  If there are two contiguous but separate
> write calls, there can be an arbitrary delay between them at the read
> end.  Just because the read for the first part succeeded doesn't mean
> that the read for the second part will succeed.

Excuse me while I repeat that a few dozen times to myself....

> - Hari
> --
> Raja R Harinath ------------------------------ harinath@cs.umn.edu
> "When all else fails, read the instructions."      -- Cahn's Axiom
> "Our policy is, when in doubt, do the right thing."   -- Roy L Ash

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
|  __                         a.k.a. Eric B. Mitchell |
|  |_) .  _  _|      _|  _     ericmit@ix.netcom.com  |
|  | \ ( (_ (_| (_| (_| (/_   www.netcom.com/~ericmit |
| How's My Programming?   Call:  1 - 800 - DEV - NULL |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+