[prev in list] [next in list] [prev in thread] [next in thread] 

List:       proxy-suite
Subject:    Re: [proxy-suite] Solaris 8 problem solved
From:       Marius Tomaschewski <mt () suse ! de>
Date:       2002-02-14 14:07:18
[Download RAW message or body]

On Mon, Feb 04, 2002 at 07:40:51PM +0100, Pascal Gienger wrote:
> But I don't know WHY Solaris has this behaviour.
> 
> It is quite simple. To be short:
> A second I_NREAD ioctl is needed after one is failing with len=0. Funny
> isn'it ?
> 
> So I tried this (on com-socket.c):
> 
> # diff com-socket.c.orig  com-socket.c
> 996c996
> <       int len, cnt, nsock;
> ---
> >        int len, cnt, nsock, erg;
> 1043c1043
> <       if (ioctl(hls->sock, I_NREAD, &len) < 0) {
> ---
> >        if ((erg=ioctl(hls->sock, I_NREAD, &len)) < 0) {
> 1048a1049,1059
> >          if ((erg==0) && (len==0))
> >          {
> >                debug (1,"second read try, I_NREAD got %d bytes.",len);
> >                usleep(10000);
> >                if ((erg=ioctl(hls->sock, I_NREAD, &len)) < 0) {
> >                        hls->xerr = errno;
> >                        syslog_error("can't get num of bytes: %s %d=%s",
> >                                hls->ctyp, hls->sock, hls->peer);
> >                        return;
> >                }
> >          }
> 1069c1080
> <       if (len == 0) {
> ---
> >        if ((len == 0) && (erg <= 0)) {
> 
> 
> And, suddenly, all works like it should.
> Connecting from slow clients to fast servers and vice-versa are working
> without having to modify MaxRecvSize.
> 
> Is there an explanation for this besides a "bug"?

Hmm... it seems to be a select or I_NREAD bug in Solaris...
IMHO select shouldn't fireup if no data is avaliable except
it has got a EOF.

Gruesse,
 Marius Tomaschewski <mt@suse.de>
--
 SuSE Linux AG, Nürnberg - SuSE Labs, Product Developement
 PGP public key available:   http://www.suse.de/~mt/mt.pgp
 Fprint:  EA 1F 92 75 1A F9 82 07  A1 28 DE 7A 32 E8 97 18

[prev in list] [next in list] [prev in thread] [next in thread]