- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Tue, 23 Jan 1996 17:52:21 -0500
- To: Erik Selberg <speed@cs.washington.edu>
- Cc: www-lib@w3.org, frystyk@w3.org
Erik Selberg writes: > I finally tracked down why my app has been appearing to be so > sluggish... in the 4.0a6 release, we needed to define the function > HTEventRequestTerminate, which would be called when a request was > finished. This function was great, as it could be used to put the > request into some sort of ready Q and then cause the HTEvent_Loop > function to exit. I know - that was a dictatorial discission from my point :-( However, I did some real thinking and this is my argument: 1) The return value exit solution using HTEventRequestTerminate() doesn't work well if using an external event loop. Especially if the event loop is used in other applications as well. 2) The solution was really a special example of a more generic problem: Both before and after a request has been issued, an application may want all kinds of functionality to be executed. Typical examples are before: - cache check - proxy gatewaying - etc. after - logging - history list - redirection <- new in 4.0C - authentication <- new in 4.0C - etc. The new Net callback API allows all of this and furthermore it reduces the Library core to be a registry for actions. This keeps the core independent of extending the set of actions to be executed. You can read more about the Net API at http://www.w3.org/pub/WWW/Library/User/Using/Net.html > Unfortunately, there no longer appears to be any way to have the > functionality of this beastie. I had incorrectly assumed that you now > put this function, or another function like it, into the loop using > HTNet_addAfter(). However, if HTEventRequestTerminate returns > non-HT_OK, then it just cancels the string of callbacks. It does > nothing to the actual event loop, which was the desired effect. Another result of the Net callback API is that terminating a "thread" is now independent of terminating a request which means that threads may live longer than a single request. However, it also means that the application looses the ability of affecting the event loop in the NET call back functions - exactly as you describe. > I've been digging around in the source, and so far I've been unable to > come up with anything resembling what I need --- which is some > callback / flag / thingy which, upon successfully loading a URL, quits > the HTEvent_Loop. As near as I can see, the various __DoUserCallback > calls will always return HT_OK unless a serious error, such as a > memory outage or something, occur. It would be reasonable to have a "event shutdown" function in the Event manager that simply exits the event loop and returns control to the application. Something like extern HTEvent_shutdown (void); How this exactly is going to be implemented depends on the event loop. -- Henrik Frystyk Nielsen, <frystyk@w3.org> World-Wide Web Consortium, MIT/LCS NE43-356 545 Technology Square, Cambridge MA 02139, USA
Received on Tuesday, 23 January 1996 17:52:29 UTC