External Plugin returning too quickly
Brad Fuller
brad at sonaural.com
Mon Nov 21 01:28:41 UTC 2005
Bert Freudenberg wrote:
>
> Am 20.11.2005 um 03:42 schrieb Brad Fuller:
>
>> 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!
>
>
> 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?
brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20051120/43dc6d8b/attachment.htm
More information about the Vm-dev
mailing list