How does the Thread API actually work?

[Elijahlorden 1]

After reading through the wiki page on the OpenOS Thread API, it seems that Threads allow for preemptive yielding.  What I am wondering is how this is accomplished, since (afaik) there is no way to implement preemptive yielding with normal Lua coroutines.

[Ta©ti Tac0Z 2]

the thread api is really simple but really power full a simple exaple chould be the following:

local thread = require("thread")
local event = require("event")
local keyb = require("keyboard")
local computer = require("computer")

thread.create(function()--creating the thread
    while true do--beeping loop
      local e,_,_,key = event.pull("key_down")
        --this is a timple while loop witch will beep evreying time you press on enter
        if keyb.keys.enter == key then
          computer.beep()
        end
  end
end)

print([[as you can see after this print function we have a print(math.huge) basicly locking up the 'main-scope' forever
but becuse the 'beeping loop' is inside a thread (witch creates a new so called 'scope' the 'beeping loop' is not effected

now when you press Ctrl, Alt + C you'll notice that you need to do it two times becuse the computer will interupt
the thread first in that oder

a simple explasion of the thread api is simply to run a function witch is almost not effected by the 'main scope' and other threads

lua is 'one-thread-only' meaning that lua doesn't make a new irl thread (a new process nor a new process in java) so the
thread api is really laying to you and emulating/facking an extra thread besicly the computer will go back and forward
betwine the 'main scope' and the threads thats why you have too have a yielding fuction (os.sleep, event.pull, ect) in the thread and 'main scope' else it will block evrying thing]])

os.sleep(math.huge)

 

Edited September 24, 2018 by Ta©ti Tac0Z
chanced language type in the code window

[Ta©ti Tac0Z 2]

ohhh btw computer.beep is not a yihlding function

BUT it is a blocking function meaning that evreying thing will be blocked and stoped while its beeping

(why computer.beep is a little useless some times)

[payonel 21]

2 hours ago, Elijahlorden said:

it seems that Threads allow for preemptive yielding

Our OpenOS threads are not preemptive, but they are also not overtly cooperative. The primary purpose of the thread library was to provide a seamless threading api that doesn't require you to manage the threads, but just trust that they will resume and yield on their own schedule (following one basic rule [continue reading])

Here is the key to understand. There is a single common limitation to your threads (openos threads) and every other normal program you write for OpenOS (and any program on OC machines) : They must periodically make a system yield (i.e. computer.pullSignal). Note that event.pull and os.sleep also call computer.pullSignal. Even calling coroutine.yield on your bottom level coroutine is sufficient (doing so is similar in affect to calling computer.pullSignal or event.pull with no timeout argument). All of these methods are functionally equivalent to computer.pullSignal, which is the "system yield", which you must do periodically. And running code in an openos thread has the same requirement, otherwise it would continue to run and rob the cpu from running other code that would otherwise know to system-yield. The trick I built into the threading library, is that when a user thread makes a system yield call, the threads transparently yields to the threading manager and can switch between programs.

Another key design I put into the thread library was that code in a thread that is using the results of the pullSignal calls (event.pull, etc) should behave identically whether it is run in a user thread or on the main system process (where everyone is normally running all of their programs, without using the thread api). To a degree, your code shouldn't know (or shouldn't have to know) that it is running in a thread (at least from my library design point of view). Your reasons for pulling event signals, yielding, making child coroutines (or even more child threads) should all behave the same whether you're in a thread yourself, or on the main system process. Yes, this particular design feature was a tremendously complex puzzle to solve, and EXTREMELY satisfying to get working

[Elijahlorden 1]

Thanks for the responses!  I think I misread the wiki.  I thought there was some magic happening here that was allowing for preemptive yielding, hence my confusion.  I appreciate the explanation, you saved from trying to pick through the Thread API myself!

[payonel 21]

well...there is plenty of magic in it reading through the source would still be quite rewarding