[PD-dev] per-thread storage in Pd in support of pdlib - discussion?

[IOhannes m zmoelnig]

-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8X3jgACgkQkX2Xpv6ydvTbmwCfZgKiMlP9xG3t9hRagZu2oPkt
XyIAoMF3uwuevcUsunjj0Q5BPfywnxqj
=UInL
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20120119/8cdd39fb/attachment-0001.bin>