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