This issue is to discuss a potential future implementation of a global coroutine manager. This would be a system similar to rednet.run that allows a user to define add a global coroutine to manage events at the top level. It could also behave somewhat like a process manager.

The main concern with this issue is:- how far should this go? How much do we want to overhaul CraftOS?

I'm trying to build one just like the muti-shell we have now (I just want to get rid of the task bar)
the problem is I don't know how to set up the coroutines to handle it since to my understanding they use a set to stone amount of functions (can't change while active) so I need to work around it and force it to change , any help would be nice , PS I did look at the muti-shell code but its built around the idea of having a taskbar so I have to start scratch
please note this isn't going to be an api because of how it needs to run in line with the program

I'll have a crack at this, expect a PR in the next few days

where can I get it as I need to look at it and might implement it (even if I have to update the code to make it work)

the github message right below the one you quoted:

#280.

the github message right below the one you quoted: #280.

i tried to impart it but the code is to complex for the simple need , i do need some help the problem I'm facing is the muti-coroutine part from my understanding I don't have the knowledge required to build the muti-coroutine , i do and have made a simple coroutine manager but that's it

Do we not already have such a manager in the form of the parallel API, which is used to start rednet.run? Seems easiest to me to simply expand that - say each coroutine started by a waitForAny/waitForAll call got a custom parallel table, with additional functions for influencing that particular call. These would be rigged to allow for the probing of coroutine IDs, the addition of new ones, the ability to kill some without ending an "Any" call, the ability to immediately end an "All" call, and so on.

This would only allow a given coroutine to add a new one "at the top level" if already running as a direct child of the top level. That seems preferable to me, though - the result would basically be a lower-level version of the multishell API, and I can't see it needing any changes to CraftOS itself, nor any other existing code.

The only time I've wanted this sort of functionality was when I was building an fs wrapper that relied upon rednet messaging. But I imagine OS developers would love it, as it'd allow for a less hackish TLCO than is currently required.

I'm closing this for now, as I personally don't wish to implement this.

I'm perfectly happy to talk about potential ways of doing this if someone's prepared to have a stab, similarly will happily consider merging if someone submits a PR to the CC repo. It's just not something that I see CC:T needing to solve directly.

Apologies for bumping a closed issue, but I have just created something that does this. Maybe it's worth reopening this issue, discussing how I could improve the program, and prepare it for implementation?
It's called syssm. The relevant portions are the chunk of code meant to be placed in the startup.lua file, and the shell program to allow for analysis of all services.

I've thought about this sort of thing a couple of times, and I feel the "optimal" design would just be closest to what BombBloke already suggested (well, my interpretation of it).

parallel.waitForAll and parallel.waitForAny return some sort of "coroutine manager" object, with :add(function), :remove(not sure) (and maybe :stop()) functions. Then the top-level manager can just be exposed on the os API.

I think the advantage here is we have a system which can be generalised for other use-cases. A lot of programs end up implementing their own coroutine/threading manager, so it'd be nice if we can adapt the parallel API to at least serve more use cases, even if not all of them.

I'll have a crack at this, expect a PR in the next few days