• knowing other threads instruction pointers 9and being able to stop/resu

    From fir@3:633/10 to All on Thursday, June 11, 2026 22:50:58
    Subject: knowing other threads instruction pointers 9and being able to stop/resume them)

    Bonita Montero pisze:> Am 11.06.2026 um 10:44 schrieb fir:

    Bonita Montero pisze:

    Real coroutines aren't possible with C since with native coroutines you
    need functions that can be suspended and resumed.

    c lasks some low lewel core management imo -it is more visible in
    multicore times..but even in old times there was something like
    interrupts - who allowed theoretically but probably also practically
    freeze a branch and resume it - so somemechanics of multthreading
    was even on 1core machines - i remember it was in 8-bit c64 really

    Coroutines have nothing to do with multithreaded programming,
    but they can be used to have sth. more lightweight than threading.
    BTW it appeared to me that (as i said teh above it would be good to have
    controll on cores from c, like this sleep() is a minimal controll
    function) that it would be nice to have something like that

    if(core1.ip >= foo.begin && core1.ip <= foo.end) hold(core1);

    //....

    resume(core1);

    or

    if(core1 in foo) hold core1;

    //etc


    i mean other cores (or threads, maybe it should be threads) have its ip
    pointer (instruction pointer) so it would be just NICE to be able to
    read it in another thread and just check where it is this avoidling LOCKS/mutexes

    interesting idea imo

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thursday, June 11, 2026 22:57:10
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    fir pisze:
    Bonita Montero pisze:> Am 11.06.2026 um 10:44 schrieb fir:

    Bonita Montero pisze:

    Real coroutines aren't possible with C since with native coroutines
    you
    need functions that can be suspended and resumed.

    c lasks some low lewel core management imo -it is more visible in
    multicore times..but even in old times there was something like
    interrupts - who allowed theoretically but probably also practically
    freeze a branch and resume it - so somemechanics of multthreading
    was even on 1core machines - i remember it was in 8-bit c64 really

    Coroutines have nothing to do with multithreaded programming,
    but they can be used to have sth. more lightweight than threading.
    BTW it appeared to me that (as i said teh above it would be good to have
    controll on cores from c, like this sleep() is a minimal controll
    function) that it would be nice to have something like that

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    //....

    resume(core1);

    or

    if(core1 in foo) hold core1;

    //etc


    i mean other cores (or threads, maybe it should be threads) have its ip pointer (instruction pointer) so it would be just NICE to be able to
    read it in another thread and just check where it is this avoidling LOCKS/mutexes

    interesting idea imo

    it could be said that those locks /mutexes are in this respact idiotic
    becouse it makes you program blindly - like blind, becouse you dont know
    where your other threads are - where in fact it is an information
    quite avaliable and instant...even it seems weird people was so blunt
    to go in this blind mode ...but real assembly people like they say
    somewhat died (fortunatelly im here ;c )

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thursday, June 11, 2026 23:07:55
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    fir pisze:
    fir pisze:
    Bonita Montero pisze:> Am 11.06.2026 um 10:44 schrieb fir:

    Bonita Montero pisze:

    Real coroutines aren't possible with C since with native
    coroutines you
    need functions that can be suspended and resumed.

    c lasks some low lewel core management imo -it is more visible in
    multicore times..but even in old times there was something like
    interrupts - who allowed theoretically but probably also practically
    freeze a branch and resume it - so somemechanics of multthreading
    was even on 1core machines - i remember it was in 8-bit c64 really

    Coroutines have nothing to do with multithreaded programming,
    but they can be used to have sth. more lightweight than threading.
    BTW it appeared to me that (as i said teh above it would be good to
    have
    controll on cores from c, like this sleep() is a minimal controll
    function) that it would be nice to have something like that

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    //....

    resume(core1);

    or

    if(core1 in foo) hold core1;

    //etc


    i mean other cores (or threads, maybe it should be threads) have its ip
    pointer (instruction pointer) so it would be just NICE to be able to
    read it in another thread and just check where it is this avoidling
    LOCKS/mutexes

    interesting idea imo

    it could be said that those locks /mutexes are in this respact idiotic becouse it makes you program blindly - like blind, becouse you dont know where your other threads are - where in fact it is an information
    quite avaliable and instant...even it seems weird people was so blunt
    to go in this blind mode ...but real assembly people like they say
    somewhat died (fortunatelly im here ;c )

    one yet could note that cpus could implement "breakpoints" that would
    work instead of locks/mutexes

    note you enter some pice of code you dont want other thread to anter set
    a breakpoint on given ip adressenter the pice of code then clear the breakpoint (breakpoint should be adress value in some breakpoint
    register) - if other thread/s are not here they will dont even notice
    this - but if they are ast you they will just hold on breakpoint

    there is some details here to consider but i think its better than locks/mutexes (i may be wrong as presenty i dont even auite remember
    what locks/mutexes are but i seem to remember they should be worse)

    still its also kinda "blind" scheme so maybe this one with just knowing
    ip's of other threads seems generally more promising imo (in some way
    at least)

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thursday, June 11, 2026 23:27:59
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    fir pisze:
    fir pisze:
    Bonita Montero pisze:> Am 11.06.2026 um 10:44 schrieb fir:

    Bonita Montero pisze:

    Real coroutines aren't possible with C since with native
    coroutines you
    need functions that can be suspended and resumed.

    c lasks some low lewel core management imo -it is more visible in
    multicore times..but even in old times there was something like
    interrupts - who allowed theoretically but probably also practically
    freeze a branch and resume it - so somemechanics of multthreading
    was even on 1core machines - i remember it was in 8-bit c64 really

    Coroutines have nothing to do with multithreaded programming,
    but they can be used to have sth. more lightweight than threading.
    BTW it appeared to me that (as i said teh above it would be good to
    have
    controll on cores from c, like this sleep() is a minimal controll
    function) that it would be nice to have something like that

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    //....

    resume(core1);

    or

    if(core1 in foo) hold core1;

    //etc


    i mean other cores (or threads, maybe it should be threads) have its ip
    pointer (instruction pointer) so it would be just NICE to be able to
    read it in another thread and just check where it is this avoidling
    LOCKS/mutexes

    interesting idea imo

    it could be said that those locks /mutexes are in this respact idiotic becouse it makes you program blindly - like blind, becouse you dont know where your other threads are - where in fact it is an information
    quite avaliable and instant...even it seems weird people was so blunt
    to go in this blind mode ...but real assembly people like they say
    somewhat died (fortunatelly im here ;c )

    i guess i saved assembly people today (11.6.2026)...

    why i think so?

    becouse old assembly has some situation/rules that allowed them to
    controll cpu with each cycle and byte and that was so nice.. without
    this i say above (what i think is like totaly not noticed in wide community..multithreading assembly is lost - but if you add this
    what i say - i mean basics of inter core immediate communication
    like passing minimal data like ip's and registers from one to another
    it is able to put multicore assembly fun again ;c indeed it seems
    nice that ine core can give commands to other cores very strict and
    efficient

    (teh efficiency is ofc not maybe known to me but as thise cores reside
    in one chip it shouldnt be too slow i guess..it would be probabbly
    possible to give side cores even ultra fast ultra small tasks and that
    could be nice

    no collisions appear when stright cooperation is on

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Friday, June 12, 2026 01:30:59
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Friday, June 12, 2026 04:01:33
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    Lawrence D?Oliveiro pisze:
    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??


    what race condition?

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Friday, June 12, 2026 03:17:33
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    On 6/11/2026 7:01 PM, fir wrote:
    Lawrence D?Oliveiro pisze:
    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??


    what race condition?

    Yikes!

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Friday, June 12, 2026 13:22:57
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    fir pisze:
    Lawrence D?Oliveiro pisze:
    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??


    what race condition?

    it obviously is quite new situation - for example if you read IP of
    another thread/core it still moves on forward so in such expressions
    when you test IP it can be already not here - but it is all to be
    handled, that what coding is

    also im not sure if modern threads do not work like those old ones that
    can be freezed on interrupts (?) that could be also problematic
    but in old times i remember the interupts can be masked and unmasked
    and yet probably this is not in case

    still other methids of communication between threads are posiblle like

    if thread is doin domething it sas flag wnen he presently is ilie

    current_t1 = 'collisions'
    /..
    cirrent_t2 ='rasterizing';
    //..

    and other thread can simply read it - i think if each tread only writes
    its own current occupation flag and other only reads it it not bring collisions...it is also an option imo to align times of cpu to given microseconds (sorta like sleep bot not sleep(how many) but sleep( until
    time) - that could schedule conroll flow in time


    overally this is quite good idea becouse it brings c to much lower lewel
    of controll - where it should be



    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Friday, June 12, 2026 12:25:46
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    On 6/12/2026 4:22 AM, fir wrote:
    fir pisze:
    Lawrence D?Oliveiro pisze:
    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??


    what race condition?

    it obviously is quite new situation - for example if you read IP of
    another thread/core it still moves on forward so in such expressions
    when you test IP it can be already not here - but it is all to be
    handled, that what coding is

    also im not sure if modern threads do not work like those old ones that
    can be freezed on interrupts (?) that could be also problematic
    but in old times i remember the interupts can be masked and unmasked
    and yet probably this is not in case

    still other methids of communication between threads are posiblle like

    if thread is doin domething it sas flag wnen he presently is ilie

    current_t1 = 'collisions'
    /..
    cirrent_t2 ='rasterizing';
    //..

    and˙ other thread can simply read it - i think if each tread only writes
    its own current occupation flag and other only reads it it not bring collisions...it is also an option imo to align times of cpu to given microseconds (sorta like sleep bot not sleep(how many) but sleep( until time) - that could schedule conroll flow in time


    overally this is quite good idea becouse it brings c to much lower lewel
    of controll - where it should be



    Have you ever used C11 wrt its support for threads? No all that bad.
    Pretty cool. Afaict, the only way we can simulate per-cpu is using
    affinity masks (os specific) and cross our fingers that the OS keeps
    them threads pinned down.

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Saturday, June 13, 2026 13:44:00
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    Chris M. Thomasson pisze:
    On 6/12/2026 4:22 AM, fir wrote:
    fir pisze:
    Lawrence D?Oliveiro pisze:
    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??


    what race condition?

    it obviously is quite new situation - for example if you read IP of
    another thread/core it still moves on forward so in such expressions
    when you test IP it can be already not here - but it is all to be
    handled, that what coding is

    also im not sure if modern threads do not work like those old ones that
    can be freezed on interrupts (?) that could be also problematic
    but in old times i remember the interupts can be masked and unmasked
    and yet probably this is not in case

    still other methids of communication between threads are posiblle like

    if thread is doin domething it sas flag wnen he presently is ilie

    current_t1 = 'collisions'
    /..
    cirrent_t2 ='rasterizing';
    //..

    and˙ other thread can simply read it - i think if each tread only
    writes its own current occupation flag and other only reads it it not
    bring collisions...it is also an option imo to align times of cpu to
    given microseconds (sorta like sleep bot not sleep(how many) but
    sleep( until time) - that could schedule conroll flow in time


    overally this is quite good idea becouse it brings c to much lower
    lewel of controll - where it should be



    Have you ever used C11 wrt its support for threads? No all that bad.
    Pretty cool. Afaict, the only way we can simulate per-cpu is using
    affinity masks (os specific) and cross our fingers that the OS keeps
    them threads pinned down.
    in c you know what is goin under the hood - to the extent of roughly
    knowing assemblu, call conventions, stack working, how loops look like
    and things like that (back day it was even better becouse now some
    assembly debbuging come out of daily practice -
    though i was doing it yet like 10 years ago etc - now indeed
    i not do it to much (sadly)

    with those threads from libraries the thing is different and its much
    worse becouse you dont know the thing bac to te cpu
    lewel as i mentioned - and that should be mended..

    some need to establish the grounds how to do it
    (multicore business) on assembly level..and users/coders
    need to know

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Saturday, June 13, 2026 14:44:42
    Subject: Re: knowing other threads instruction pointers 9and being able to stop/resume them)

    On 6/13/2026 4:44 AM, fir wrote:
    Chris M. Thomasson pisze:
    On 6/12/2026 4:22 AM, fir wrote:
    fir pisze:
    Lawrence D?Oliveiro pisze:
    On Thu, 11 Jun 2026 22:50:58 +0200, fir wrote:

    if(core1.ip >= foo.begin˙ && core1.ip <= foo.end) hold(core1);

    ?Knock-knock!?
    ?Race condition!?
    ?Who?s there??


    what race condition?

    it obviously is quite new situation - for example if you read IP of
    another thread/core it still moves on forward so in such expressions
    when you test IP it can be already not here - but it is all to be
    handled, that what coding is

    also im not sure if modern threads do not work like those old ones that
    can be freezed on interrupts (?) that could be also problematic
    but in old times i remember the interupts can be masked and unmasked
    and yet probably this is not in case

    still other methids of communication between threads are posiblle like

    if thread is doin domething it sas flag wnen he presently is ilie

    current_t1 = 'collisions'
    /..
    cirrent_t2 ='rasterizing';
    //..

    and˙ other thread can simply read it - i think if each tread only
    writes its own current occupation flag and other only reads it it not
    bring collisions...it is also an option imo to align times of cpu to
    given microseconds (sorta like sleep bot not sleep(how many) but
    sleep( until time) - that could schedule conroll flow in time


    overally this is quite good idea becouse it brings c to much lower
    lewel of controll - where it should be



    Have you ever used C11 wrt its support for threads? No all that bad.
    Pretty cool. Afaict, the only way we can simulate per-cpu is using
    affinity masks (os specific) and cross our fingers that the OS keeps
    them threads pinned down.
    in c you know what is goin under the hood - to the extent of roughly
    knowing assemblu, call conventions, stack working, how loops look like
    and things like that (back day it was even better becouse now some
    assembly debbuging come out of daily practice -
    though i was doing it yet like 10 years ago etc - now indeed
    i not do it to much (sadly)

    with those threads from libraries the thing is different and its much
    worse becouse you dont know the thing bac to te cpu
    lewel as i mentioned - and that should be mended..

    some need to establish the grounds how to do it
    (multicore business)˙ on assembly level..and users/coders
    need to know

    Have you ever tried to simulate per-cpu data in user space? We can try
    to use thread affinity.

    --- PyGate Linux v1.5.16
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)