Re: WWWLib 3.1 & blocking I/O

> Yep, this seems to be mostly working.  My message handler gets called with
> FD_CONNECT, then one or more FD_READ notifications.  In each case, I call
> HTTPLoad().  This part is working, I can see the received bytes in the read
> buffer.
> 
> However, I never get an FD_CLOSE notification.  I would think that (on a
> GET) the HTTP server would close the socket after sending the information to
> the client.  The FD_CLOSE flag is included in the lEvent in
> WSAAsyncSelect(), and I do get other notifications.  I have even tried to
> close the socket (closesocket()) from a button press event.

This is a unix simplification which you might consider a bug. The close 
notification is not sent because it is not registered using the 
HTEvent_register() function. In the current model you can only have one 
callback function pr. socket at a time which have to be the protocol load 
module (for example HTLoadHTTP()). There is no room for having a callback for 
FD_CLOSE, another for FD_READ etc. at the same time what is what you want.
What I think that you can do is to register the callback function just before 
you close the socket.

PS: In version 3.1 of the Library HTLoadHTTP() is not directly a callback 
function as it still uses some bits from the old event model. However, in the 
new version that I am giving out in an alpha version to W3C members in a 
couple of days, HTTLoadHTTP _is_ a callback function just like the others and 
the NT based event model provided by Charlie Brooks is fully integrated with 
the Library. This version does also have a net manager that controls the 
number of open sockets and enables persistent connections.

-- 

Henrik Frystyk Nielsen, <frystyk@w3.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA

Received on Friday, 22 September 1995 17:30:21 UTC