Re: other Solaris-related problems

[Raja R Harinath <harinath cs umn edu>]

"Brandon S. Allbery" <allbery@hilfy.ece.cmu.edu> writes:
> I've tried to figure this one out but can't track what's happening:  when 
> using the background-properties capplet to set the background color, 
> everything seems to work fine until you click "OK" in the color picker.  
> Actually, it seems okay after that as well, but if you then click "Try" (or 
> "OK") you get the wrong color in the monitor display and a *different* wrong 
> color in the desktop background.  The swatch color seems to be random; at the 
> moment it seems to like a dark maroon color (0.48/0/0.27), but the desktop 
> background that gets applied is always #00ff00.
> 
> Another, very recent problem:  I build with esd support.  Over the past few 
> days, I have to kill esd and/or start GNOME programs with --disable-sound or I 
> get an "unknown protocol" error from the esd code and the program dies with 
> "Broken pipe" (presumably esd shut down the connection on it and there's no 
> error checking in the GNOME sound code):
> 
> 	2@hilfy:508 B$ gnomecc
> 	(09) proto: unknown protocol request:  0x7761726e
> 	Broken Pipe
> 	2@hilfy:509 B$ 
> 
> 0x7761726e looks like 'warn' to me???

This is a bug in `esound'.  `gnome-triggers' does
esd_sample_getid(..., "warning") -- the string "warning" is sent over
the network after a ESD_PROTO_SAMPLE_GETID request.  The daemon is
probably getting confused, and thinks that the "warning" stuff is a
different protocol request.

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.

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.

- 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