[forwarded] libwww - Event Handler

------- Forwarded Message

From nusser@chappaqua.wi-inf.uni-essen.de  Wed Aug  7 04:14:56 1996
Return-Path: nusser@chappaqua.wi-inf.uni-essen.de
Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by anansi.w3.org 
(8.7.5/8.7.3) with ESMTP id EAA06067 for <frystyk@anansi.w3.org>; Wed, 7 Aug 
1996 04:14:55 -0400 (EDT)
Received: from chappaqua.wi-inf.uni-essen.de (chappaqua.wi-inf.uni-essen.de 
[132.252.53.137]) by www10.w3.org (8.7.5/8.7.3) with ESMTP id EAA05092 for 
<libwww@w3.org>; Wed, 7 Aug 1996 04:14:28 -0400 (EDT)
Received: (from nusser@localhost) by chappaqua.wi-inf.uni-essen.de 
(8.7.4/8.7.3) id JAA01818 for libwww@w3.org; Wed, 7 Aug 1996 09:45:22 +0200
From: Stefan Nusser <nusser@chappaqua.wi-inf.uni-essen.de>
Message-Id: <199608070745.JAA01818@chappaqua.wi-inf.uni-essen.de>
To: libwww@w3.org
Subject: [forwarded] libwww - Event Handler
Date: Wed, 7 Aug 96 09:42:00 MET


I just noticed that BUG-reports should be sent to libwww@w3.org.
Well, here it is again.

- -stefan

Forwarded message from [nusser] sent originally on Sun, 28 Jul 96 19:07:46 
MET :
: Henrik,
: 
: I have just tried to write an event handler based on  the newest version of
: libwww (@(#) $Id: HTEvntrg.c,v 2.38 1996/06/07 04:39:54 eric Exp $).
: I noted the following behaviour:
: 
: If a callback function is registered for a connect ( FD_CONNECT      
0x10), it will
: actually be waiting for the socket to become WRITABLE (as explained in a 
: comment, under UNIX this should have the same effect and the select() 
system-call is
: limited to read-, write- and except-conditions). But when the 
callback-function is
: invoked, it is NOT passed the FD_CONNECT condition it registered for, but 
instead the
: FD_WRITE condition which actually incurred on a UNIX-System. 
: 
: Furthermore, some protocol modules (as e.g. HTTP) depend on this 
behaviour. If 
:  HTLoadHTTP() (HTTP.c) is called with the SockOps it actually registered 
for, the 
: state machine won't work. 
: 
: I think that the event-handlers should work as described in the 
documentation and call
: the callback functions with EXACTLY the same SockOps they registered for. 
: In this case, all protocol modules should be checked for dependencies on 
the described
: behaviour. In HTTP.c the following change should fix the problem:
: 
: (line 601, HTTP.c)
: 
: 		if (HTRequest_isDestination(request)) {		
: 		    HTEvent_register(net->sockfd, request, (SockOps) FD_READ,
: 				     HTLoadHTTP, net->priority);
: 		    HTRequest_linkDestination(request);
: 		}
: 		http->state = HTTP_NEED_REQUEST;
: 		/* previous value: FD_CONNECT */
: 		ops = FD_WRITE;
: *		^^^^^^^^^^^^
: 	    } else if (status == HT_WOULD_BLOCK || status == HT_PERSISTENT)
: 		return HT_OK;
: 	    else
: 		http->state = HTTP_ERROR;	       /* Error or interrupt */
: 
: 	    break;
: 
: 	    /* As we can do simultanous read and write this is now one state */
: 	  case HTTP_NEED_REQUEST:
: 
: Please keep me posted if you will include these changes in the next 
version or if I
: am completely wrong.  
: 
: -stefan
: 
: --
: Stefan Nusser
: Wirtschaftsinformatik und Softwaretechnik        
: Universitaet GH Essen, FB5
: Altendorfer Strasse 97-101, Eingang B, D-45143 Essen
: Tel.: +49 (0201) 81003-19, Fax:  +49 (0201) 81003-73

Received on Thursday, 8 August 1996 14:51:12 UTC