- From: <jose.kahan@w3.org>
- Date: Thu, 24 Oct 1996 23:24:37 +0200 (MET DST)
- 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 UTC