questions about task_complete event uppon calling .list() or .size()

[2f5f3a1b567e0611949455401526cba2]

I got a co-routine that calls my_peripheral.list()
problem is, it seems to yield and my main event loop catches the event.

what is the intended way to handle this?

[fatboychummy]

Without knowing your actual code, there's no real advice I can give you about this other than just... Ignore the event?

Could you post your code?

[fatboychummy]

Oh, hold on, I missed the part about a coroutine. Coroutines should receive events based on three filters:

1. When you coroutine.resume the coroutine, it will return a value. This value is from os.pullEvent, being the event filter (e.g. "modem_message", etc). If this value is present, only resume the coroutine if the event matches that filter (or is "terminate").
2. Similarly, a coroutine.resumecall may return nothing. In this case, resume it for any received event.
3. As noted in 1, the event "terminate" bypasses all filters. Always send this event forward.

I recommend against working with raw coroutines though, especially if you aren't entirely sure how the event system works. Instead, use the parallel library, or if you wish to understand how it works, read its source.

[2f5f3a1b567e0611949455401526cba2]

here is a minimal (but verbose example i threw together to show the issue)

local function foo()
	local a = peripheral.wrap("left")
	print("-- Wrapped peripheral")
	a.list()
	print("-- Unreachable")
end

local co = coroutine.create(foo)
print("-- Created Coroutine")
coroutine.resume(co)
print("-- Coroutine yeilded")
local event  = { os.pullEvent() }
print("Got event ".. event[1])

Output:

-- Created Coroutine
-- Wrapped peripheral
-- Coroutine yeilded

[2f5f3a1b567e0611949455401526cba2]

I do understand that calling .list() yields,
but i tried to catch the task_complete event and call coroutine.resume()
but it did not work, so i reckon i just ask.

[fatboychummy]

Yes, just catching the event is not enough. You need to actually send the event back to the coroutine again, via coroutine.resume.

coroutine.resume(co, table.unpack(event)) -- passes the event to the coroutine

Again, highly recommend looking at how parallel does it, or just using parallel instead of running your own coroutine library. There's a lot of small issues that can occur when working manually with coroutines.

But I believe you may also be getting stuck on another hiccup of coroutines... Coroutines are not Threads. They do not run in the background. Lua is single-threaded, and so everything runs sequentially. Calling coroutine.resume actually switches to running your coroutine, then when it yields, it stops running.

[2f5f3a1b567e0611949455401526cba2]

But there seems to be some confusion, (probably because i am terrible at writing)
I am not trying to implement threads, nor do i want threads, i want co-routines and so parallel is not something i can nor want to use for my design.

When i get this task_complete event, i need to know which of the co-routines caused it <- not something i know how.
if i did know which co-routine i need to know how to resume it <- you answered this thanks a ton :D

From reading the parallel library source, it seems like that run loop just passes the event to every routine. which isn't the behavior i want, nor something i can do as i don't have a list of all my co-routines.

Is there a way to map, task_complete.number into the co that caused the event such that i know which co-routines to resume?

the issue i am facing:

if i have multiple co-routines say CoA and CoB

if CoA are in a yielded state because: it is waiting on a task_complete.
and CoB then calls foo.list()

now i will yield to main thread, and when i then get the task_complete event
i can't know which of the two (CoA, CoB) to resume

Resuming CoB using the event from CoA can mess things up, as it can cause CoA to become stale

(i do not have a list of all my co routines - they are not threads and i am not trying to use them as such).

[2f5f3a1b567e0611949455401526cba2]

from "dan200/computercraft/api/lua/TaskCallback.java"

    public MethodResult resume(@Nullable Object[] response) throws LuaException {
        if (response.length < 3 || !(response[1] instanceof Number eventTask) || !(response[2] instanceof Boolean isOk)) {
            return pull;
        }

        if (eventTask.longValue() != taskId) return pull;
        ....

it seems like this forces me to check every co-routine (which expects a task_complete event)
unless there is a way for me to know the taskid some other way.

yeah looks like internal stuff:

java/dan200/computercraft/core/computer/Computer.java

    private final AtomicLong lastTaskId = new AtomicLong();
    
    ....
    long getUniqueTaskId() {
        return lastTaskId.incrementAndGet();
    }

ngl i am disappointed. but i am glad i can safely call coroutine.resume() on all awaiting such a event

[fatboychummy]

CC's design style is that events are essentially sent to everything, and that "thing" is meant to be the one that handles whether it should deal with it or not. There is the basic filtering rules that you can use, but otherwise it's all handled on the caller's side.

Parallel will work with this just fine. In fact, I use it extensively for many things like this.