Re: HTEvent_Loop: why stop at the first one?

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;
> }
>