dccm misbehaving on Solaris 9

Vernon Schryver vjs@calcite.rhyolite.com
Wed Mar 1 23:52:41 UTC 2006


> From: Andy Rudoff 

> using dcc on Solaris.  Three ideas come to mind:
>
> 1. build dcc 64-bit on Solaris, so the problem goes away.

I'm uncomfortable assuming that all Solaris systems on which DCC clients
might be installed can run 64-bit code.  It never pays to underestimate
the ages of still active systems.

> 2. workaround the problem by changing the way dcc calls fdopen/fopen
>     (i.e. play the trick of moving non-stdio descriptors higher to free
>     up the lower descriptors, and/or handle the failure case in some
>     new, interesting way)

Other threads are continually opening and closing new file descriptors.
For example with dccm, there's sendmail milter code doing accept() that
I can't change.  Even if I could change it, I don't see an alternative
to either wrapping every place that might allocate an FD with in a mutex
or some really nasty ugly and probably unworkable games with dup2(),
fflush(), and never using fopen() or fclose() after the application is
rolling.

> 3. workaround the problem by linking dcc against a different stdio.
>     (sfio at http://www.research.att.com/sw/tools/sfio/ is a common
>     choice for this exact issue)

Shipping or depending on other packages is a whole other can of worms
that I've so far avoided and escaped with the DCC.

The best solution is to do my own buffering.  I think there are only
one invocation each of fopen() and fdopen() that are at risk.  Because
of locking on other things, they produce at most 4 concurrent streams.
No fanciness such as with setbuf(), fseek() or ungetc() is involved.
This solution is merely a boring pain with some stability risks.

8-bit FDs...amazing....no wonder Sun had so much trouble with lockd.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.