Le 2012-02-16 à 01:06:00, Rich E a écrit :
I think it's something like a team developing on the same codebase; 2-3
people definitely gets the job done faster than 1, partly because it is
easy to discuss your work (or in computing, synchronize).
There are few parallels to be made from teamwork
So, trying to get back to the original goal of this post, how about using a
(uint)pd_context in lieu of static variables? :)
On Wed, Feb 15, 2012 at 5:09 AM, Mathieu Bouchard wrote:
> Le 2012-02-14 à 11:14:00, Charles Henry a écrit :
>
> The point of the original remark is that you always lose s
Le 2012-02-14 à 11:14:00, Charles Henry a écrit :
On 2/13/12, Mathieu Bouchard wrote:
Do you understand what I say, or you just repeat what I was replying to ?
I thought I understood--was there something I missed?
I wouldn't have known that from your reply. It seemed to just continue
wher
On 2/13/12, Mathieu Bouchard wrote:
> Do you understand what I say, or you just repeat what I was replying to ?
I thought I understood--was there something I missed? The point of
the original remark is that you always lose some of your potential
computing power when trying to use multiple resour
Le 2012-02-13 à 21:15:00, Charles Henry a écrit :
On 2/11/12, Mathieu Bouchard wrote:
Depends on how you count it. You may also see it as a bunch of computers
in which 0 computer can do task T in time N, but they can join together to
form 1 (or more) computer(s) that can do task T in time N or
On 2/11/12, Mathieu Bouchard wrote:
> Le 2012-01-26 à 14:45:00, Charles Henry a écrit :
>
>> When talking about cluster computing, I had someone once ask: "Is that a
>> case where the whole is greater than the sum of its parts?" "It's less.
>> Always less."
>
> Depends on how you count it. You may
Le 2012-02-08 à 09:08:00, IOhannes m zmoelnig a écrit :
another reason is, that with accessor-functions you can more easily stay
binary compatible both backward and forward than with directly accessing
the struct.
Depends what you think can be changing in the future...
sure you can do someth
Le 2012-01-26 à 14:45:00, Charles Henry a écrit :
When talking about cluster computing, I had someone once ask: "Is that a
case where the whole is greater than the sum of its parts?" "It's less.
Always less."
Depends on how you count it. You may also see it as a bunch of computers
in which 0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-02-08 00:36, Mathieu Bouchard wrote:
>
> I mean that this context could be accessed directly if there's no reason
> to use accessors. But if locking has to be done before and after
> accessing (some of) those members, then it's nice to have a
Le 2012-01-19 à 10:11:00, IOhannes m zmoelnig a écrit :
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 in
Le 2012-02-07 à 18:49:00, Mathieu Bouchard a écrit :
Sharing gensym is useful so that one can prepare lists and messages
without having to lock everytime. This can allow to run the audio thread
on one processor while cooking up a big list on the other processor.
Otherwise the non-audio thread
Le 2012-01-19 à 01:09:00, Peter Brinkmann a écrit :
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 assumption
Le 2012-01-16 à 09:43:00, IOhannes m zmoelnig a écrit :
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?
Or just structs. You'd have a t_pdglobal type containing all the glob
Le 2012-01-14 à 22:16:00, Peter Brinkmann a écrit :
* In many cases, the audio thread is beyond the control of the
programmer. For instance, if you want one Pd instance per JACK client,
or one Pd instance per audio unit in iOS, then you just register a
callback, and you have no real idea whic
Le 2012-01-14 à 13:04:00, Miller Puckette a écrit :
The question I'd like to rais is this: would it suffice to make Pd
instances be per-thread?
This means I'd have to switch threads every time I want to send a message
to pd. In my app, I have a main thread, and I have a pd-audio thread. The
> I see the next important step as making the general cases easier to
> handle. A per-thread context such as IOhannes and Peter describe above
> seems like the best approach to allowing a program to run multiple
> instances of pd in a much more predictable manner, while it still allows
> for backw
I'm really happy to see this conversation.
On Fri, Jan 27, 2012 at 7:45 AM, Charles Henry wrote:
> On Wed, Jan 25, 2012 at 5:32 PM, Peter Brinkmann
> wrote:
>
> > I don't think users have anything to gain from fine-grained control of
> > threads. That seems like an optimization hint that may o
On Jan 25, 2012, at 6:32 PM, Peter Brinkmann wrote:
>
>
> On Wed, Jan 25, 2012 at 5:38 PM, Charles Henry wrote:
> On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann
> wrote:
> >
> > Hi Chuck,
> > Check out the early bits of this thread --- various use cases already came
> > up along the way:
>
On Wed, Jan 25, 2012 at 5:32 PM, Peter Brinkmann
wrote:
> I don't think users have anything to gain from fine-grained control of
> threads. That seems like an optimization hint that may or may not be
> helpful, depending on a lot of factors that are not obvious and will differ
> from machine to
On Wed, Jan 25, 2012 at 5:38 PM, Charles Henry wrote:
> On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann
> wrote:
> >
> > Hi Chuck,
> > Check out the early bits of this thread --- various use cases already
> came
> > up along the way:
> > http://lists.puredata.info/pipermail/pd-dev/2012-01/0179
On Wed, Jan 25, 2012 at 11:46 AM, Peter Brinkmann
wrote:
>
> Hi Chuck,
> Check out the early bits of this thread --- various use cases already came
> up along the way:
> http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html. The short
> version is that libpd is being used in such a wide
Le 2012-01-25 à 12:46:00, Peter Brinkmann a écrit :
Threading is an implementation detail that users shouldn't have to worry
about,
If you sweep threading under the carpet, it makes the carpet turns into an
evil mutant who will come back to eat you.
I warned you.
_
Hi Chuck,
Check out the early bits of this thread --- various use cases already came
up along the way:
http://lists.puredata.info/pipermail/pd-dev/2012-01/017992.html. The short
version is that libpd is being used in such a wide range of settings that
you can come up with legitimate use cases for
On Sat, Jan 14, 2012 at 3:04 PM, Miller Puckette wrote:
> To Pd dev -
>
> For some time the good folks who brought us pdlib have been asking how
> one could make it possible to run several instances of Pd in a single
> address space.
Maybe I have on my audio-colored glasses--but that's just where
Oops, I just realized that I sent my reply IOhannes and didn't cc pd-dev...
On Thu, Jan 19, 2012 at 4:11 AM, IOhannes m zmoelnig wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> >> right now, only #1 is possible at all and it takes some effort on the
>
> >> "thread host" (the exter
-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 prov
On Mon, Jan 16, 2012 at 3:43 AM, IOhannes m zmoelnig wrote:
>
> i think there are 2 use cases for multi "threading".
>
> #1 access a single instance of (lib)pd from multiple threads
> #2 allow multiple instances of (lib)pd to co-exist in global memory.
>
That's right, and there are real use cases
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
i think there are 2 use cases for multi "threading".
#1 access a single instance of (lib)pd from multiple threads
#2 allow multiple instances of (lib)pd to co-exist in global memory.
right now, only #1 is possible at all and it takes some effort on t
Yikes... sounds like back to the drawing board.
The odd thing is, do make thread-local storage, the good C compiler
folks (and linker folks, etc) had to do all the work you'd need to make
a switch-all-my-static-storage-when-I-ask-you-to feature which would open
up all sorts of other ways to do thi
Hi Miller,
Thanks for your message!
I'm afraid thread-local instances would be problematic from the point of
view of libpd:
* The most common structure of a libpd-based application involves two
threads, a GUI thread and an audio thread, where the GUI controls the Pd
engine by invoking libpd funct
I don't really have a sense of other possible approaches and their
advantages/disadvantages. Couldn't this issue also be solved in the logic of
the code? A lot of the current global variables could easily be visible in each
thread, and still be fully functional. Things like sys_libdir and the
To Pd dev -
For some time the good folks who brought us pdlib have been asking how
one could make it possible to run several instances of Pd in a single
address space.
The question I'd like to rais is this: would it suffice to make Pd instances
be per-thread? This could be done by going through
32 matches
Mail list logo