For a completely different solution: you could write an external which pins the current thread to a specific core with a message. Then you just have an instance of [threadpin] in each (sub)process and set the desired core via a startup message like 'pd -send ";cpu 1"'.

On the other hand, this could actually be a new startup flag for Pd, e.g. "pd -cpu 1".

Christof

On 20.03.2020 18:26, Csaba Láng wrote:
Chuck,

naturally i use [shell]. Your advice sounds like the ultimate solution.
Now the same I have to make for the rest of the cores to keep the main Pd out of the core where the subprocess is bound.

Thanks a lot,

Popesz

On Fri, Mar 20, 2020 at 6:03 PM Charles Z Henry <[email protected] <mailto:[email protected]>> wrote:

    Hi Popesz,

    Are you using [ggee/shell] ?

    Here's an example that works on my linux machine

    [taskset -c 2 $_ -noaudio >/dev/null & P=$! && echo $P  && wait $P(
    |
    [ggee/shell]
    |
    [f ]    ///the PID

    When I run that command, $_ is a bash variable (see [env( - [shell] -
    [print] for full environment) that has the full path to the pd binary
    in use.  You may have to replace "$_" with something more appropriate
    to your system
    I added -noaudio, because my first pd process is handling audio I/O.
    I don't need stdout from pd itself, so I added ">/dev/null".  The
    process shows up in top or htop with those arguments included.  You
    could distinguish between your processes by some environment variable
    or set of options to pd in the command.
    "& P=$! " launches pd into the background and records a variable P for
    its PID.  There may be other ways of doing this.
    "&& echo $P && wait $P"  causes the shell started by [shell] to output
    the PID to stdout (the left outlet).  Without "wait $P", [shell]
    outputs a bang from its right outlet immediately.  Using "wait $P"
    allows [shell] to maintain the status of the process, and it outputs a
    bang when the process ends.

    Using htop, I see that the process starts and runs on CPU "3".
    Taskset must use a CPU numbering that starts at 0, and htop counts
    CPU's from 1.

    Chuck



    On Fri, Mar 20, 2020 at 10:23 AM Csaba Láng <[email protected]
    <mailto:[email protected]>> wrote:
    >
    > Dear list,
    > I am getting closer to the solution of binding process to a
    certain core with taskset.
    > e.g. taskset 0xa gedit will bind the gedit to the tenth core.
    >
    > Now the problem is that I cannot identify the subprocess by its
    name as it will be pd too, and the PID will be always different so
    cannot use that number too.
    > What would be the logical solution for starting the subprocess
    from pd with the taskedit command?
    >
    > Thanks in advance for any help,
    >
    > Popesz
    >
    > On Thu, Mar 5, 2020 at 11:14 PM IOhannes m zmölnig
    <[email protected] <mailto:[email protected]>> wrote:
    >>
    >> On 3/5/20 10:48 PM, Charles Z Henry wrote:
    >> > On Thu, Mar 5, 2020 at 4:14 AM Max <[email protected]
    <mailto:[email protected]>> wrote:
    >> >>
    >> >> A glance at the System Monitor CPU history graph should give
    you an idea.
    >> >>
    >>
    >> i usually use 'htop', which is a much improved version of top
    which also
    >> (among verious other interesting things) gives you the CPU of a
    process.
    >>
    >> >
    >> > Second, you can bind processes to certain CPUs. This is
    called "CPU
    >> > affinity" and it's controlled by the linux command
    "taskset".  This
    >> > looks like a fine explanation
    >>
    >>
    >> but keep in mind that the people who designed the muticore
    scheduling
    >> algorithms most likely will have a better idea of how to ideally
    >> distribute multiple processes onto multiple CPUs.
    >>
    >> gmsdr
    >> IOhannes
    >>
    >> _______________________________________________
    >> [email protected] <mailto:[email protected]> mailing list
    >> UNSUBSCRIBE and account-management ->
    https://lists.puredata.info/listinfo/pd-list
    >
    > _______________________________________________
    > [email protected] <mailto:[email protected]> mailing list
    > UNSUBSCRIBE and account-management ->
    https://lists.puredata.info/listinfo/pd-list


_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to