<div>Dear Marc and list,</div><div><br></div><div>A universal HTTP client is taking form, it does connect & logics & IO in a singlethread setting now properly.</div><div><br></div><div>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:</div>

<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><font face="courier new, monospace">(define r (http-request url))</font></div><div><font face="courier new, monospace"><br></font></div><div>

<font face="courier new, monospace">((r 'abort!)) ; From another thread than the one performing the HTTP request logics & IO.</font></div><div><font face="courier new, monospace">              ; (</font><span style="font-family:'courier new',monospace">Even if the abort is done at the level of HTTP request, due to the invalid</span></div>

<div><span style="font-family:'courier new',monospace">              ; protocol state the abort produces the connection needs to be taken down.)</span></div></blockquote><div><br></div><div><br></div><div>The ways I can see this could be done by would be using</div>

<div><br></div><div><ul><li>close-port<br><br></li><li>thread-interrupt! or ##thread-int! ??<br><br></li><li>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.<br>

<br></li><li>thread-terminate! (The HTTP request may be running in the user's thread, so this would require redesign)</li></ul></div><div><br></div><div>It'd be most preferable if this cancel could be done in such a way that</div>

<div><br></div><div> 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.</div>
<div>
     This includes taking care automatically of any "mutex abandoned" exceptions or alike that would otherwise come as surprises later.</div><div><br></div><div><div> 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 until timeout.)</div>

</div><div><br></div><div><br></div><div><div>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 was locked.</div>

</div><div><br></div><div>It's OK if the interrupt appears to the read/write-subu8vector caller as an IO failure i.e. #f return value.</div><div><br></div><div><br></div><div>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?</div>

<div><br></div><div>Thanks!</div><div>Mikael</div><div><br></div>