> 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---------------------------------- E-Mail: dyp@perchine.com HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 ---------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:53 EST