[comp.unix.questions] Sockets and interrupt driven I/O

HoldswoS@r4.cs.man.ac.uk (Sean Holdsworth) (02/26/90)

I am currently struggling with sockets under SUNOS 3.5. The basic problem is
trying to implement interrupt driven I/O rather than use the select call
which I can't use because of other activity within the same process.

The current state of play is that I've succeeded in arranging to have the
arrival of data at a socket signalled by SIGIO. This was done using the usual
incantations for setting the owner of the socket to be the process group of
the process to which the socket belongs, making the socket non-blocking and
setting its ASYNC flag.

The problem arises because if I write to a socket and get back an EWOULDBLOCK
error I have no way of knowing, other than polling, when the socket again
becomes writable. I had hoped that when the state of the socket changed from
blocked to unblocked that a SIGIO would be generated but from my experiments
this appears not to be the case.

The documentation provided by Sun is quite sketchy on this matter but I had
hoped that the behaviour of SUNOS would be similar to 4.3BSD. According to
my BSD documentation when the ASYNC flag is set the kernel watches for a
change in the status of the socket and arranges to send a SIGIO when a
read or write becomes possible.

Does anyone out there know if what I'm trying to do is possible under SUNOS
and if so what I'm doing wrong? Alternatively is there an easier way of
going about solving this sort of problem?

PS. The sockets are stream sockets in the internet domain using tcp protocol.
    The work is being done on a Sun 3/50.

-----------------------------------------------------------------------------
                             Sean Holdsworth.
   EDS Group,   Room 407 IT Building,   Department of Computer Science,
   University of Manchester,   Oxford Road,  Manchester,   M13 9PL,  UK.
   Janet: HoldswoS@uk.ac.man.cs                     Tel: +44-61-275-6293
   UUCP:  ...!uunet!mcsun!ukc!man.cs!HoldswoS       Fax: +44-61-275-6280
   Inet:  HoldswoS%cs.man.ac.uk@nsfnet-relay.ac.uk  Int: 6293
-----------------------------------------------------------------------------

chris@mimsy.umd.edu (Chris Torek) (03/06/90)

In article <1011@m1.cs.man.ac.uk> HoldswoS@r4.cs.man.ac.uk (Sean Holdsworth)
writes:
>... if I write to a socket and get back an EWOULDBLOCK error I have no
>way of knowing, other than polling, when the socket again becomes writable.
>I had hoped that when the state of the socket changed from blocked to
>unblocked that a SIGIO would be generated but from my experiments this
>appears not to be the case.

If you examine the file netinet/tcp_input.c, you will find code of the
form:

	if (act > so->so_snd.sb_cc) {
		tp->snd_wnd -= so->so_snd.sb_cc;
		sbdrop(&so->so_snd, (int)so->so_snd.sb_cc);
		ourfinisacked = 1;
	} else {
		sbdrop(&so->so_snd, acked);
		tp->snd_wnd -= acked;
		ourfinisacked = 0;
	}
-->	if ((so->so_snd.sb_flags & SB_WAIT) || so->so_snd.sb_sel)
		sowwakeup(so);
	tp->snd_una = ti->ti_ack;

The line marked `-->' above is the cuprit:  For the sake of efficiency,
the TCP code calls sowwakeup(so) (a macro for sowakeup(so, &so->so_snd))
only if a process is waiting for data to go out, or is selecting, or was
selecting not long ago.  When a process uses asynchronous I/O, however,
neither SB_WAIT nor sb_sel are set.

There are a number of ways around the problem.  One of them involves no
kernel changes: simply arrange for some process to select on that socket.
Any process will do, including your own.  Thus:

	omask = sigblock(sigmask(SIGIO));
	if ((n = write(socket_fd, buf, count)) < 0 && errno == EWOULDBLOCK) {
		fd_set out;
		struct timeval tv;
		FD_ZERO(&out);
		FD_SET(socket_fd, &out);
		tv.tv_sec = 0;
		tv.tv_usec = 0;
		n = select(socket_fd + 1, (fd_set *)0, &out, (fd_set *)0, &tv);
		if (n > 0) {
			/* can write now, try again: must have unblocked
			   while we were fiddling with select() */
			n = write(socket_fd, buf, count);
			if (n < 0 && errno == EWOULDBLOCK)
				... now what? ...
		}
		/* cannot write, but made so->so_snd.sb_sel non nil so that
		   the tcp code will call sowakeup() later */
		n = 0;	/* clobber the error */
	}
	if (n < 0)
		... handle output error ...
	(void) sigsetmask(omask);

Simpler fixes, if you have kernel source, are to remove the test from
tcp_input.c or to assert SB_WAIT in sosend() when returning EWOULDBLOCK.
(The latter would preserve efficiency, and protect any other code that
has the same bug as tcp_input.c, such as the XNS code [spp_usrreq.c].)
The bug has been fixed in 4.4BSD by removing the test from both
netinet/tcp_input.c and netns/spp_usrreq.c.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris