OpenEuphoria

Re: Rob: More trouble with PD-source

• Posted by Robert Craig <rds at RapidEuphoria.com> Nov 29, 2005
• 570 views

Elliott Sales de Andrade wrote:
> I can confirm that without the StatusProc, the example does work correctly.
> Speed is somewhat important in these cases since audio buffering is involved.
> The DSPTest, for example, is machine-staggeringly slow when run through the
> PD source. Still, it is able to run without crashing, albeit quite slowly.
> However,
> I do not think speed is as important in the StatusProc since it is meant for
> saving downloaded data.

I just tried a little experiment with NetRadio.exw.
If I add a small delay:
   for i = 1 to 1000 do
   end for
before returning from the callback, exw runs NetRadio ok.
But if I increase the loop to 10,000 ... 100,000 ... 1,000,000
then things become unstable, and eventually it crashes with
one of those weird errors. So there is a problem if the callback 
takes too long, and maybe also if other processing takes too long. 
I'm guessing the PD source (exw eu.ex) is too slow for certain 
demanding operations. It doesn't crash when it's simply displaying
a GUI. It's when some data is being transferred at high-speed.
I think your BASS stuff is requiring a minimum level of speed.

> It may well be that Eu's lack of thread-safety is the cause of this problem.
> However, I do not know why it would still work with the official interpreter.
> The errors are quite random. Sometimes, only half an error message is printed,
> without the actual error showing up, even in the ex.err file. This is
> sometimes
> a sign of the problem with thread-safety, but I cannot confirm it.

If you run multiple threads in a non-thread-safe environment,
corruption can happen. For example, if two threads are
allocating space from the same heap at the same time, the
heap could get corrupted and all hell could break loose,
causing the interpreter to behave in a totally insane way.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com