W3C home > Mailing lists > Public > www-lib@w3.org > October to December 1996

Re: HTEvent_Loop: why stop at the first one?

From: <jose.kahan@w3.org>
Date: Thu, 24 Oct 1996 23:24:37 +0200 (MET DST)
Message-Id: <199610242124.XAA01738@tuvalu.inrialpes.fr>
To: selberg@cs.washington.edu (Erik Selberg)
Cc: www-lib@w3.org
Erik,

Here are my $0.02.

Before getting to __ProcessFds, you have passed through
a call to select, where the fdsp variables get set up. The
present scheme, as far as I understand it, allows you to handle
multiple events as they happen. This includes user keyboard
interruptions, spurious closing of connections, etc. 
With your proposed cheme, __ProcessFds would block everything
until it finished processing all the sockets requiring
attention. So, a user may not be able to do a keyboard interrupt
as easily as before. And if some high-priority events happen,
the event loop would not see them until __ProcessFds would have
finished.

I pass now my email pen to Henrik, in case he has something 
more to say about your question or my analysis :-)


-Jose

> I was wondering why this was chosen, vs. something like:
> 
> PRIVATE int __ProcessFds( fd_set * fdsp, SockOps ops, CONST char * str) 
> {
>     SOCKET s ;
>     int e;
>     if (THD_TRACE)
> 	TTYPrint(TDEST, "Processing.. %s socket set. max_sock is %d\n",
> 		str, max_sock);
>     
>     for (s = 0 ; s <= max_sock; s++) {
>         if (FD_ISSET( s, fdsp)) 
> 	e = __DoCallback( s, ops);
>         if (e != HT_OK) return e; /* error condition */
>     }
>     return HT_OK;
> }
> 
Received on Thursday, 24 October 1996 17:24:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2007 18:18:27 GMT