13 messages in at.iem.pd-devRe: clock function thread safety - wa...| From | Sent On | Attachments |
|---|---|---|
| guenter geiger | Jun 2, 2003 6:09 am | |
| Thomas Grill | Jun 2, 2003 7:04 am | |
| Frank Barknecht | Jun 2, 2003 8:04 am | |
| Frank Barknecht | Jun 2, 2003 8:06 am | |
| Frank Barknecht | Jun 2, 2003 8:07 am | |
| guenter geiger | Jun 2, 2003 8:21 am | |
| Miller Puckette | Jun 2, 2003 8:53 am | |
| guenter geiger | Jun 2, 2003 9:19 am | |
| Frank Barknecht | Jun 2, 2003 10:05 am | |
| chris clepper | Jun 2, 2003 11:00 am | |
| Thomas Grill | Jun 2, 2003 11:59 am | |
| Miller Puckette | Jun 2, 2003 3:26 pm | |
| Miller Puckette | Jun 2, 2003 3:29 pm |
| Subject: | Re: clock function thread safety - was Re: [PD-dev] devel_0_37 branch | |
|---|---|---|
| From: | chris clepper (ccle...@artic.edu) | |
| Date: | Jun 2, 2003 11:00:12 am | |
| List: | at.iem.pd-dev | |
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".
cheers Miller
Is it not possible to do a mutex thread with the DSP function? Would this assure that the DSP calls would have enough time to complete without fighting sys_pollgui() and the other calls for time? Or would those have to be threaded as well? It seems like when DSP is on that all other tasks need to be subservient to the computing of audio to ensure proper audio performance.
It would be really great to have some sort of solution to this within the Pd scheduler.
cgc