[racket] can custodian-shutdown-all interrupt an #:atomic callback?

On Sep 10, 2011, at 12:44 PM, Matthew Flatt wrote:

> At Sat, 10 Sep 2011 12:00:19 -0700, John Clements wrote:
>> 
>> 
>> However, looking more carefully at the stack trace below, I think I've misread 
>> it.
>> 
>> This dump came from a DrRacket hang (hence the SIGQUIT), and based on my 
>> reading of Apple CoreAudio documentation, it looks to me like the call in 
>> frame 11 of thread 0 to > is waiting on a mutex which I'm guessing 
>> is held by thread 10, which I believe is the main audio processing thread.  
>> The action in thread 0 is triggered by a custodian action, as shown by frame 
>> 27 of that thread.
>> 
>> Thread 10 is blocked, though. I initially believed it was in the middle of a 
>> callback, but looking more carefully, it now seems to me that it was blocked 
>> on a queue_callback, which surprises me, because I didn't think that a 
>> queue-callback could block. I suppose there has to be *some* synchronization 
>> in there, though.
>> 
>> If I'm reading this correctly, then the custodian-ness could be a red
>> herring; it could be that any racket thread calling CloseStream or
>> another audio function could cause this problem. If queue_callback
>> can block, I'm not sure how to resolve this.
> 
> To double-check my understanding:
> 
> * A callback uses `#:async-apply' and is invoked on OS thread 10,
>   which is waiting to send the callback to OS thread 0 where it can
>   run.

Yes... Is there generally only one thread that can run such a callback?

> 
> * OS thread 0 is busy trying to shut down the audio process that
>   locked by OS thread 10 during the callback (so it's stuck and not
>   checking for any queued callbacks to run).

Looks that way to me, yes.

> 
> Without knowing more about the API, my only idea is that maybe the
> close function could run in its own OS-level thread, although that
> sounds difficult to set up.
> 

Perhaps I'm missing something obvious; I'll keep thinking about this, thanks.

John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4624 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20110910/30981509/attachment.p7s>