daveb@gonzo.UUCP (Dave Brower) (12/18/88)
On 4.xBSD, one can do a connect(2) call on a socket that has been set
no-delay, and the operation will return. But you can't do anything on
the socket until a select on the fd comes alive.
Is there some similar method one can use to write a non-blocking
streams/TLI based connection routine?
(This is of interest in, say a window system where select is the heart
of the event loop. You'd want to make sure that other events coming in
won't be blocked out by a connect request to something on a slow
network)
Thanks,
-dB
--
If life was like the movies, the music would match the picture.
{sun,mtxinu,hoptoad}!rtech!gonzo!daveb daveb@gonzo.uucpdougm@ico.ISC.COM (Doug McCallum) (12/19/88)
In article <488@gonzo.UUCP> daveb@rtech.com (Dave Brower) writes: ... >streams/TLI based connection routine? > >(This is of interest in, say a window system where select is the heart >of the event loop. You'd want to make sure that other events coming in >won't be blocked out by a connect request to something on a slow >network) > Yes, there are a couple of ways to do it. If all you are concerned with is incoming connection requests, then just "poll" on the STREAM you will receive connection requests on and do a t_listen if the poll shows that something can be gotten from the descriptor. The poll system call performs much the same function as select in a BSD system. You could also set the descriptor to O_NDELAY and have a non-blocking descriptor. This type of asynchronous usage is described in the documentation on STREAMS and the man pages for the t_* functions mention it as well. Of course, AT&T chose to allow poll to only work on STREAMS devices in V.3 based systems. Some vendors may have extended poll to other types of file descriptors but you can't count on it but it does work on STREAMS and TLI.
dougm@ico.ISC.COM (Doug McCallum) (12/20/88)
In article <12903@ico.ISC.COM> dougm@ico.isc.com (Doug McCallum) writes: >In article <488@gonzo.UUCP> daveb@rtech.com (Dave Brower) writes: >... >>streams/TLI based connection routine? >> >>(This is of interest in, say a window system where select is the heart >>of the event loop. You'd want to make sure that other events coming in >>won't be blocked out by a connect request to something on a slow >>network) >> My response didn't indicate how to do this with connect although it was hinted at. If the STREAM obtained with a t_open() is put into O_NDELAY mode, the t_connect() will not block. When poll says there is an event, a t_look (I think I said t_listen before) will indicate if it is a response to the connect request and a t_rcvconnect can be used to complete the connection. Look at the t_rcv* functions for more details. Unlike BSD sockets, the TLI primitives have separate events/operations for things like connect and connect response and receiving an incoming connect indication and the actual acceptance of the connection. Sockets tend to have more done in the calls. One nice thing in TLI is that after t_listen gives you the connection request you can decide to accept or reject based on information provided by the t_listen. For more casual programming, sockets tend to be a lot simpler.