[lkml]   [2001]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Problems with kernel-2.2.19-6.2.7 from RH update for 6.2
> connect() is used to complete asynchronously started connect.
> While connection is not complete connect() returns EALREADY.
> When connection is established, it succeeds. If connection fails,
> it returns an error (the same, which you get with getsockopt()).
> So, right way is to repeat connect() after poll() returned POLLOUT,
> it will either complete connection or return an error to you.

:-))) You will never think it works like this. And you is the first one fro
whom I hear this.

> Actually, this classic interface is very ugly. Seems, it is the only place,
> where O_NONBLOCK is used not to do something nonblocking, but to start
> an asynchronous operation. And all these terrible unique error codes:
> EINPROGRESS, EALREADY suck. Thank to bsd people, who preferred ugly
> hacks instead of developing some AIO interface. :-)
> It is so ugly (it is the only place where kernel has to maintain history
> of user syscalls in addition to tcp state), that it is even offending
> that people do not use it; it means that it simply pollutes kernel. :-)

> > the combination which works. Actually thttpd also uses this (if I am
> > not mistaken).
> Where? httpd does not connect().

For read/write. Although it is incorrect to compare as thttpd is serving more
than one connect.

> If they do this after accept(), it is really silly. Pure useless syscall.
> > The problem here is that I need to tune timeout for: each connection,
> > and for
> > connect, and read/write separately. If you could give me an advise how
> > to do this more effective, I would be really glad.
> I see. If tuning is goal, it is right way. Amount of syscalls is the same
> as with alarm, but logic is cleaner.

Logic with alarms will not work in multithreaded case.

> Though, with read/write SO_RCVTIMEO/SO_SNDTIMEO is preferred.
> Unfortunately, linux-2.2 seems to be the only OS not implemented this.
> [ I am not sure about Solaris though. ]
> In linux-2.4 they work for connect/accept too: SO_SNDTIMEO for
> connect, SO_RCVTIMEO for accept.

I assume that using SO_RCVTIME/SO_SNDTIME would be better in terms of
performance. Maybe it worse of it to upgrade to 2.4.x, and rewrite network
layer to use sync IP... I will think about it. How many times better it would
be (approximately)? if we assume that I have lots of connects which transfers
small amount of data in each (1-2K).

Sincerely Yours,
Denis Perchine

FidoNet: 2:5000/120.5
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:58    [W:0.189 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site