Re: Network write() stalls with 'Resource temporarily unavailable'

[Rob Davies <robdavies@worldnet.att.net>]

> You could do this certainly, as to whether its a good idea or not would
> really depend upon you application. 
> 
> What it won't do for you is increase the rate at which data is sent through
> the socket. You can only increase the rate by waiting for the socket to
> gain round trip timing information, or by opening more than one socket
> at the same time and sending in parallel.

I'm mainly interested in making sure that one socket returning
EWOULDBLOCK doesn't hold up the flow of traffic on other sockets
connected to other systems. I'm trying to emulate the functionality of
some VMS SYS$QIO code with ASTs that I've had to substantially re-write
....

> Spawning a thread if the socket blocks
> is not efficient unless the amount of data to be transferred is large (and
> thus time consuming). You might want to consider pre-spawned thread pools
> and also using select() to feed a number of sockets whenever they are
> ready.
> For really high performance, I'd suggest one thread per processor (assuming
> an SMP system) and select() in a loop allocating the incoming connections
> to threads in a round robin fashion as a starting point.

Unfortunately, I don't have SMP Linux systems yet, though I'm already
considering my Alpha Beowulf cluster implementation having seen the new
1U high rackmount Alpha Servers running RedHat 6.1 they were demo-ing at
Linux World in NYC last week ... ;-)

For the time being I've implemented spawning a thread that then sits in
select() for up to 10 seconds waiting for a write flag to be set on the
descriptor, at which point it retries the write once, then exits. If it
times out, it kills the socket.

It appears to take care of my current problem ... I'll figure out a
nicer solution later ...

>From your description of the slow-start algorithm implemented, it
shouldn't be a huge problem, as most of the network connections will be
long-lived (hours/days) so this should only affect the first few packets
in a connection, or if network problems occur.

> > 
> > An associated question : 
> > 
> > Lets say I block on the second packet, and spawn a new (blocking) thread
> > to take care of it, and I want to send another packet. If I spawn a
> > (blocking) thread to take care of this one, can I be certain that they
> > will complete in the order the write() functions took place ?
> >
> You can be sure that the write() functions will take place in the order
> that they are called, but to ensure that they are called in a particular
> order you'd have to have some kind of synchronisation between the threads.
> Probably this won't give the effect you want to acheive though,

I'm hoping I never end up with two packets blocking, but as far as I can
tell in the current application I'm converting, it doesn't care too much
... other programs I have still to complete might though ... by then
I'll have a better solution ;-)

I was thinking of the 'network write thread' concept, where I spawn a
thread to select() on write, then send the next outstanding packet for
that file descriptor. This is basically how the old VMS routine did it
with AST routines triggered when a write was possible. I still need to
figure out how to queue-up and keep track of the outstanding packets for
each file descriptor ... 


Goal #1 : Get it working first, THEN optimise it ;-)


Regards,

Rob.
-----------------------------------------------------------------------------
To unsubscribe from this list, send a mail to majordomo@dreamtime.org
containing the line "unsubscribe linux-decnet"
-----------------------------------------------------------------------------