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
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:
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
i'm trying to do a cleaner solution, since 1. waiting for the audio layer callback with open lock might produce some problem with messages to pd 2. for that time we have a very bad message passing resolution (with 1024 samples, about 20 ms)
... have to think a bit ...
cheers... tim
i might have an idea, using a lock as flag ...
is why I've always avoided using threads for anything else but that!)
well, but when they are working, they are lovely ...
cheers ... tim