On 24 April 2011 10:26, Edward Z. Yang wrote:

No, you have to use the 'interruptible' keyword.

Good, I need them to be uninterruptible. So I guess I can apply uninterruptibleMask_ only to the 'acquire lock' in the following code from my usb library: https://github.com/basvandijk/usb/blob/async/System/USB/Internal.hs#L1593 Thanks, Bas

On 24 April 2011 18:58, Edward Z. Yang wrote:

Well, that will result in a race where, if the foreign call gets interrupted, the asynchronous exception will get queued up and fire immediately once the FFI call completes,

Well the whole block of code is under a mask_ so if FFI calls are not interruptible the queued up exceptions should not be fired. I did a quick test that throwed 1000 exceptions to a thread executing that piece of code but with the uninterruptibleMask_ only around the 'acquire lock'. As expected only the first one got through.

thus enabling libusb_cancel_transfer to be called but not acquire lock to be called. Is that the desired semantics?

No, the desired semantics are that after calling the asynchronous libusb_cancel_transfer, we must wait for the transfer to terminate. Although it's correct to put the uninterruptibleMask_ only around the 'acquire lock' I think I leave it as it is. If for some reason the interruptibility of FFI calls changes in the future I will be safe. Better be safe than sorry. Edward, thanks for your insights. Bas

On 24/04/2011 21:16, Edward Z. Yang wrote:

Excerpts from Bas van Dijk's message of Sun Apr 24 16:10:46 -0400 2011:

...

Well the whole block of code is under a mask_ so if FFI calls are not interruptible the queued up exceptions should not be fired.

Ah, I didn't know that. I think it would be extremely surprising for users if FFI calls ever grew the semanticcs that they unmasked exceptions, so I don't think you have to worry too much about it.

This also makes me wonder if "interruptible" in the sense that we're using it for FFI coincides with the sense of "interruptible" as used by mask. I suspect it might not (that is, a mask will still prevent interruptible FFI calls from receiving interrupts.) I will have to investigate this.

I think they should coincide. That is, if you declare a foreign import to be interruptible, then it can be interrupted inside `mask` but not `uninterruptibleMask`. Indeed, that is the semantics we implemented (I just checked the code). Cheers, Simon