SO_LINGER (ugh)

[Marcus Brinkmann]

On Mon, Oct 15, 2001 at 01:43:52AM +0200, Marcus Brinkmann wrote:
> I checked in a similar implementation that works correctly,

Mmmh.  I just read up about SO_LINGER in Stevens, and it seems that the
implementation ismostly bogus.  As far as I can see, the sock_release only
ever happens when the port is cleaned up, so of course neither is the
process calling close() put on sleep, nor will it get the right return
value.

Implementing SO_LINGER properly would require support in glibc, and as it
seems a special RPC in the socket interface, right?  This will be slightly
harder to get right...

Anyway, I am not sure what to do.  I definitely don't want pfinet to crash
just because it doesn't support SO_LINGER correctly.  What I checked in will
make pfinet linger, it will just not return the error code.

As it was before I checked in my "fix":
(1) Application will think SO_LINGER is supported, and that close() succeeds.
  pfinet does crash when the socket is closed.

Currently, with my change:
(2) Application will think SO_LINGER is supported, and that close() succeeds.
  pfinet will linger, but it won't be able to return the error code to
  close() if not all data could be processed.

Possible way outs:
(3) If setsockopt with SO_LINGER, l_onoff==1 and l_linger != 0 (do we implement
  l_linger = 0 correctly?), return EOPNOTSUPP.  This makes applications
  compile and run normally, as they usually ignore the return code of the
  setsockopt call.  I think this might be the cleanest solution, as we don't
  lie about it.  However, it would be more helpful to at least linger, even
  if the return value of close might be incorrect, although this would mean
  to lie about the level of support.

(4) Do not define SO_LINGER.  This is likely too harsh, some applications will
  not compile (openssh), and it is also inaccurate as some variants are
  supported (l_onoff == 0 the trivial case, and maybe l_onoff==1 and
  l_linger==0, but I didn't check.)

Looking at this, I think that my change isn't too bad after all, but that
returning EOPNOTSUPP is also acceptable, and probably more accurate.  I
don't think how many applications rely on the return value of close() in the
l_onoff==1  and l_linger != 0 case, but probably not many if at all.

I think crashing is not acceptable, (3) would be much better (in fact, I
don't think any program would notice ;)

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de