Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!labrea!decwrl!decvax!savax!elrond!muffy!nawaf
From: nawaf@muffy.CalComp.COM (Nawaf K. Bitar)
Newsgroups: comp.unix.wizards
Subject: Re: Non-blocking accept(2) calls
Message-ID: <672@muffy.CalComp.COM>
Date: Fri, 4-Sep-87 10:39:41 EDT
Article-I.D.: muffy.672
Posted: Fri Sep  4 10:39:41 1987
Date-Received: Sat, 5-Sep-87 18:03:33 EDT
References: <479@radio.toronto.edu> <8395@mimsy.UUCP>
Organization: CalComp, A Lockheed Company, Hudson, NH, USA
Lines: 56
Keywords: socket non-blocking BSD
Summary: is this really what you want?

In article <8395@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <479@radio.toronto.edu> brian@radio.toronto.edu (Brian
> Glendenning) writes:
> >like to poll accept(2) periodically looking for new connections. It should be
> >non-blocking so that it doesn't adversely affect screen activity.
> >
> >So my question is - how do I make accept non-blocking? I know it can be done.
> 
> Instead of making accept nonblocking, perform it only when it will not
> block.  To find out when the latter is true, select the service socket
> (the one on which you have listen()ed) for reading:
> 
>				.
>				.
> 			nsel = select(highfd, &r, &w, (fd_set *)0,
> 				(struct timeval *)0);
>				.
>				.
> 			if (FD_ISSET(serverfd, &r)) {
> 				sourcesize = sizeof(source);
> 				newfd = accept(servfd, &source, &sourcesize);
> 				if (newfd < 0)
> 					error(...);
> 				FD_SET(newfd, &rset);
> 				FD_SET(newfd, &wset);
> 			}



In essence what has happened here is that the select() above blocks
indefinitely until some input is available.  If I understand the
original request you would rather poll once in a while and not
block at all.  I can think of three possibilities:

	i)   Use the select() as above but supply a
	     pointer to a zero-valued timeval struct
	     and thus affect a poll

	ii)  Set up the socket so that it is non-blocking;
	     this will cause accept() to return an
	     EWOULDBLOCK if no data is pending

	iii) The advanced topics section of the IPC primer
	     blurbs something about using SIGIO with
	     asynchronous I/O.  It seems to suggest delivery
	     of the signal on input availabilty - this might be
	     worth investigating further.

I hope this helps.


-- 
Nawaf Bitar
uucp:	 ...{harvard,decvax}!elrond!nawaf or nawaf@elrond.CalComp.COM
usps:    CalComp (A Lockheed Company), Display Products Division,
	 Mail Stop PTP2-2D01, CS 908, Hudson NH 03051 (603) 885 8135