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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
