Re: functionality of HTEventRequestTerminate
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
- cache check
- proxy gatewaying
- history list
- redirection <- new in 4.0C
- authentication <- new in 4.0C
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
> 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, <firstname.lastname@example.org>
World-Wide Web Consortium, MIT/LCS NE43-356
545 Technology Square, Cambridge MA 02139, USA