atom feed13 messages in at.iem.pd-devRe: clock function thread safety - wa...
FromSent OnAttachments
guenter geigerJun 2, 2003 6:09 am 
Thomas GrillJun 2, 2003 7:04 am 
Frank BarknechtJun 2, 2003 8:04 am 
Frank BarknechtJun 2, 2003 8:06 am 
Frank BarknechtJun 2, 2003 8:07 am 
guenter geigerJun 2, 2003 8:21 am 
Miller PucketteJun 2, 2003 8:53 am 
guenter geigerJun 2, 2003 9:19 am 
Frank BarknechtJun 2, 2003 10:05 am 
chris clepperJun 2, 2003 11:00 am 
Thomas GrillJun 2, 2003 11:59 am 
Miller PucketteJun 2, 2003 3:26 pm 
Miller PucketteJun 2, 2003 3:29 pm 
Subject:Re: clock function thread safety - was Re: [PD-dev] devel_0_37 branch
From:Thomas Grill (t.gr@gmx.net)
Date:Jun 2, 2003 11:59:59 am
List:at.iem.pd-dev

Hi,

What's wrong with simply putting a mutex around all of Pd? that way other threads could just make calls right into "receive" objects without having to set and wait for clock callbacks. Perhaps I'm missing something but that seems the much simpler solution for making threaded externs.

Pd's scheduler would simply lock all pf Pd whenever it issues a message or runs a DSP tick, and unlock it when it ``idles".

that sounds very reasonable and efficient. The reason why i preferred the clock functions is probably my lack of insight. Is my understanding right that there shall be something like pd_lock() and pd_unlock() functions that are used around every call into the pd API from a second thread?

best greetings, Thomas