-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-01-19 07:09, Peter Brinkmann wrote:
On 2012-01-14 22:04, Miller Puckette wrote:
To do this I'd replace all globals like
what is wrong with eliminating all directly accessible globals from the API (like "pd_objectmaker") and provide accessor functions to get (thread safe) access to them?
e.g. i would prefer if the symhash stayed global and instead access to it (via gensym()) was thread safe.
I'd rather not have any shared global state at all because that would significantly reduce the possible performance gains from concurrency (Amdahl's Law).
it seems like i was myself mixing instances and threading. indeed what i would prefer was, if i could use gensym() from another thread in a safe way. this has nothing to do with a global hashtable (and i don't see a reason why multiple instances should share a global hashtable)
right now, only #1 is possible at all and it takes some effort on the "thread host" (the external) to not fuck Pd's heap. i think Pd should be more helpful in this respect: a way to make Pd thread-safe is to eliminate global variables and if they can't (or shan't) be eliminate them properly protect them against parallel access.
As far as libpd is concerned, I would prefer not to have any synchronization inside Pd itself --- libpd can be used in a wide variety of settings, with lots of different approaches to concurrency, and so it's impossible to make any assumptions about threading at this level.
what are the actual drawbacks if e.g. clock_delay() could be used from any thread (in an external)? which assumptions are made that might not hold true in all your use cases?
my main reasoning is, that thread synchronisation is a re-curring problem that imho should not be re-implemented whenever it is needed. also a earlier attempts to fix this, using the great BIG kernel lock (aka sys_lock()), proved (at least for me) to be inadequate, as they slow down the entire processing significantly.
however, maybe i'm asking too much and what i really want is to have a standardized possibility to send messages to a Pd-instances without having to worry about threading (i use all the clock-stuff i keep mentioning mainly for doing exactly this: implementing a thread-safe message queue to send data from a worker thread back to Pd)
Of course, as you point out, Pd itself requires some synchronization in its interaction with externals, so there's a bit of a conflict there. My favorite solution would be to refactor Pd so that it has an audio library much like libpd at its core. Then Pd would be able to do all the synchronization it needs without affecting other applications that use the same library.
i have to admit i'm a bit unsure where you would draw the separation. Pd uses common infrastructures for a lot of things on different system levels: e.g. the message system is used to communicate between objects, to let the gui talk to the pd-core, to open a patch (instantiate it's objects),... while i think this is one of the strengths of Pd, i also think that this is probably the biggest problem when attempting a refactor as you describe it (but again: i might totally miss the point here)
The solution I have in mind would add an extended API that has a context parameter everywhere. In order to maintain compatibility with current code, there would be a global legacy context, and the functions in the current API would simply invoke their new counterparts with this global context.
yes that's what i wanted to say (and please forget about the make_global() idea; having a single global legacy context is of course much easier
fgmasdr IOhannes