[PD-dev] scheduler problem with SENDDACS_NO

[Miller Puckette]

There's nothing I know of to worry about there.  The dangerous thing
would have been to wait on another thread in the scheduler, since
the scheduler doesn't get rid of Pd's global lock when it calls
sys_send_dacs().

The behavior you're getting reminds me of what happened when I had some
kind of fight between two threads in readsf~/writesf~, when I didn't
have the locks set properly.  These can be hell to debug (which is why
I've always avoided using threads for anything else but that!)

cheers
Miller

On Tue, Nov 09, 2004 at 11:01:13PM +0100, Tim Blechmann wrote:
> hi miller, hi others ...
> 
> thomas grill and i experienced both some strange problems when working
> on the native asio support.
> 
> during the time waiting for the callback from the driver we did similar
> implementations that we won't wait for a pthread conditional, but return
> SENDDACS_NO to the dsp scheduler.
> 
> this had some unexpected behaviour, we both can't explain ... i could
> reproduce segfaults during realloc / free (when dragging around arrays)
> and some dsp functions (e.g. env_tilde_perform in testtone.pd). 
> in env_tilde_perform all members of the t_sigenv had been set to
> 0xb8000100 ... what means, either the pointer to the t_sigenv structure
> has been corrupted (what i doubt, since the 3 t_int pointer contains
> the write blocksize 0x40) or something happened to the data structure
> itself ...
> 
> also: when dragging around a table, memory will be freed in binbuf_text
> (after socketreceiver_doread) that points to an area in memory that
> value (0xb8000100) occurs, too ...
> 
> is there anything running in the dsp scheduler that could cause weird
> behaviour like that?
> 
> any idea is highly appreciated ...
> 
> cheers ... tim
> 
> -- 
> mailto:TimBlechmann at gmx.de    ICQ: 96771783
> http://www.mokabar.tk
> 
> After one look at this planet any visitor from outer space 
> would say "I want to see the manager."
> 				      William S. Burroughs
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/pd-dev