[gambit-list] How best cancel a read/write-subu8vector or ##device-port-wait-for-input/output! from another thread gracefully? (for abort operation on active HTTP request etc.)
mikael.rcv at gmail.com
Mon Mar 18 09:50:26 EDT 2013
Dear Marc and list,
A universal HTTP client is taking form, it does connect & logics & IO in a
singlethread setting now properly.
Would be happy to be able to cancel blocking read/write-subu8vector or
##device-port-wait-for-input/output! calls gracefully as to be able to
abort HTTP connections directly and gracefully like this:
(define r (http-request url))
((r 'abort!)) ; From another thread than the one performing the HTTP
request logics & IO.
; (Even if the abort is done at the level of HTTP request,
due to the invalid
; protocol state the abort produces the connection needs to
be taken down.)
The ways I can see this could be done by would be using
- thread-interrupt! or ##thread-int! ??
- A low timeout on any read and write IO primitive invoked, like, 0.05
seconds, and check for the cancel condition on each timeout and if not
reached, invoke the IO primitive again.
- thread-terminate! (The HTTP request may be running in the user's
thread, so this would require redesign)
It'd be most preferable if this cancel could be done in such a way that
1) The abort action's effects are limited within the scope of the code for
the respective HTTP request or connection so user code executed after the
HTTP request code is not affected by it.
This includes taking care automatically of any "mutex abandoned"
exceptions or alike that would otherwise come as surprises later.
2) The thread performing the abort action does not get blocked in turn.
(Something like that, the write-subu8vector would block a mutex in the IO
system that would make the close-port call used to interrupt it, block
To help 1), I can ensure that a thread-interrupt! or alike call is not done
after that the HTTP request code is done and the thread is back in user
code, through making a round of locking some mutex at the end of the HTTP
request and guaranteeing a thread-interrupt! never is made after that mutex
It's OK if the interrupt appears to the read/write-subu8vector caller as an
IO failure i.e. #f return value.
While I believe I could come up with a solution, I'd be very happy to learn
to know your take on it as to do this the best way?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list