Feature Requests item #3322973, was opened at 2011-06-20 11:59
Message generated for change (Tracker Item Submitted) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3322973&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata-dev
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: IOhannes m zmlnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: make clocks thread safe

Initial Comment:
when writing threaded externals, i often find myself wanting Pd to call a 
callback from the main thread, depending on the "other" thread's state.

e.g. when doing asynchronous data acquisition, i want to notify Pd when new 
data has arrived, so it can be delivered in the main thread.

the obvious way is to use t_clock, and registers a new clock_delay() event from 
within the helper-thread; Pd will then callback in the next tick.
unfortunately the clock_set(),... methods are not thread safe, possibly leading 
to corruption of the clock_setlist when accessing them simultaneously.

one workaround is to use the global sys_lock(), but i find this to terribly 
slow down the entire Pd process, esp. when i have to call sys_lock() multiple 
times before ticks. that's most likely because sys_lock() locks about 
everything.
an alternative i used in the past, is to have a special (mutex-protected) flag, 
indicating whether i already have a clock running that is waiting to be called 
back from the main thread.

however, i find this quite complicated

therefore, i propose to make the clock_delay/clock_set/clock_unset methods 
threadsafe, by internally maintaining a separate mutex that solely protects the 
clock_setlist.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3322973&group_id=55736

_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev

Reply via email to