On Tue, 9 Nov 2004, Miller Puckette wrote:
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().
I thought that maybe sys_unlock should be called before sys_send_dacs, because thats the only place that pd waits under linux. didn't doublecheck though.
Guenter
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@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@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev