External Plugin returning too quickly

> The plugin that I'm creating seems to return too quickly. I have a  
> simple test that plays a sine wave and waits 5 seconds (using  
> usleep). The problem is that it stops the sine wave and returns in  
> about a half a second (I hear the sine wave but just a blip. And no  
> errors from the external code.) The code works fine outside of  
> Squeak, but not called from Squeak.
>
> The plugin does 2 simple things:
> * Starts a stream that calls a callback routine (below)
> * The callback fills a buffer for the sine wave data and then returns
> After waiting 5secs, the main line cleans up and exits.
>
> Are there any particular issues with callbacks in Squeak? Do I need  
> to compile/link with anything special? It doesn't seem like this  
> should be a problem since Squeak is single-threaded. If anything, I  
> would think that the return would be slower not quicker. BTW,  
> usleep returns w/o error.
>
> Any ideas or pointers much appreciated!
>
> brad
>
>
> --
> Brad Fuller
> (408) 799-6124
> ** Sonaural Audio Studios **
> (408) 799-6123  West San Jose
> (408) 799-6124  Cambrian
> ________________________________
> Hear us online: www.Sonaural.com
> See me on O'Reilly: http://www.oreillynet.com/pub/au/2184
>
>

>
>
> On 19-Nov-05, at 6:42 PM, Brad Fuller wrote:
>
>> The plugin that I'm creating seems to return too quickly. I have a  
>> simple test that plays a sine wave and waits 5 seconds (using  
>> usleep). The problem is that it stops the sine wave and returns in  
>> about a half a second (I hear the sine wave but just a blip. And no  
>> errors from the external code.) The code works fine outside of  
>> Squeak, but not called from Squeak.
>>
>> The plugin does 2 simple things:
>> * Starts a stream that calls a callback routine (below)
>> * The callback fills a buffer for the sine wave data and then returns
>> After waiting 5secs, the main line cleans up and exits.
>>
>> Are there any particular issues with callbacks in Squeak? Do I need  
>> to compile/link with anything special? It doesn't seem like this  
>> should be a problem since Squeak is single-threaded. If anything, I  
>> would think that the return would be slower not quicker. BTW,  usleep
>> returns w/o error.
>>
>> Any ideas or pointers much appreciated!
>>
>> brad
>

> The plugin that I'm creating seems to return too quickly. I have a  
> simple test that plays a sine wave and waits 5 seconds (using  
> usleep). The problem is that it stops the sine wave and returns in  
> about a half a second (I hear the sine wave but just a blip. And no  
> errors from the external code.) The code works fine outside of  
> Squeak, but not called from Squeak.
>
> The plugin does 2 simple things:
> * Starts a stream that calls a callback routine (below)
> * The callback fills a buffer for the sine wave data and then returns
> After waiting 5secs, the main line cleans up and exits.
>
> Are there any particular issues with callbacks in Squeak? Do I need  
> to compile/link with anything special? It doesn't seem like this  
> should be a problem since Squeak is single-threaded. If anything, I  
> would think that the return would be slower not quicker. BTW,  
> usleep returns w/o error.
>
> Any ideas or pointers much appreciated!

> Bert Freudenberg wrote:
>>
>> Did you wrap the usleep() into a while loop checking for EINTR?
> googling, I found many instances of usleep to be a problem in  
> multithreading. One place said usleep sets an alarm signal to wait.  
> When it occurs, usleep returns. SIGALRM should not be blocked and  
> if it is, usleep will exit. This was my problem.
>
> I abandoned usleep and instead tried nanosleep. The result was the  
> same - I heard just a blip.
> So, I wrapped the call to nanosleep with blocking the signals with  
> pthread_sigmask(), called nanosleep and then unblocked the signals.
> This worked.
>
> But, I don't know why. I still don't understand how this would  
> effect the call to the library from Squeak and not as a standalone.  
> What is different, or added, with Squeak that is not with the  
> standalone test?