This has been discussed before, but has there been any solution
Currently, you can use
HTEventrg_registerTimeout(tp, request, tbcf, always)
to get a callback when any(?) of the sockets times out.
As coded currently, there is no way to recover from stuck connection
for specific object. Unless the socket in question actually returns
some error, the library will wait forever.
If you put a timeout, it does get called, but there is nothing to do,
as there is no way to identify the the stuck socket in the callback,
and if you return HT_OK, the event loop just continues as nothing had
happened. And, if you return anything else, the event loop
What is needed
When timeout on some socket/request occurs, (1) application
needs to know which request it was, and (2) application must
have a way to abort the request (HTRequest_KILL?).
In this sense, the 'request' parameter to registerTimeout is totally
misleading and useless. The callback function should get the request
of the timed out socket.
I suppose, for interactive browser this is not a problem, as the user
can just manually cancel everything, if he/she gets bored at waiting
for inlines, but for a proxy/server/robot this wont work. In such
environment a way to give up stalled transfers without terminating all
other parallel working transfers, is required.
Could the return from the timeout_handler somehow be used to force
abort of the socket connection? Thus instead of the two alternatives
== HT_OK continue as nothing happened (timeout ignored)
!= HT_OK exit event loop (abort everything)
we should have a third alternative return
== HT_??? close the sockets and have normal termination handlers
deal with them?
Of course, as currently implemented, the use of timeout value in
select is wrong. In a busy server environment the timeout may never
occur, as there are always things happening on other sockets. To solve
this, the event loop should remember for each socket when it last had
some action, and if "(current_time - last_action_time) > timeout",
then one should call the timeout_handler for this socket/request.
Markku Savela (firstname.lastname@example.org), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/