HTEvent_registerTimeout problem

This has been discussed before, but has there been any solution
presented?

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
terminates.

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
now

  == 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 (msa@hemuli.tte.vtt.fi),     Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/

Received on Thursday, 12 September 1996 06:53:44 UTC