What is a Janet fiber? What are they for?

[uvtc]

Looking at the docs for fiber, it appears to me that a fiber is quite like a function, but you never call it --- you instead (possibly repeatedly) call resume on it to let it execute. Is that the case?

It looks like you wrap a zero-arg function (possibly containing zero or more yields) in fiber/new. You can check its status with (fiber/status fbr). Does a fiber (function) run only once?

It looks like fibers have parent/child relationships with other fibers. Is that correct?

What is the purpose of fibers? It doesn't appear to me that they run in a different thread than the current thread. Do they have anything to do with multithreading?

The docs on dynamic binding say that "each fiber contains an environment table". Is this environment table based on (does it inherit from) the parent fiber?

Does my Janet program run in one "top-level" fiber?

[uvtc]

Looking at src/core/fiber.c, I don't see anything about threads, and so it's looking to me like fibers are a way to call a function but then temporarily leave it (when it yields) and then get back to it at another time (via resume).

I see from the fiber api docs that we have fiber/getenv and fiber/setenv. The dynamic bindings chapter of the docs mention contexts... In Janet, is a context another name for an environment?

[sogaiu]

My current take is that there isn't an official definition of context in Janet. Happy to find out otherwise :)

Two of the places I've seen the term used include what you pointed out in the dynamic bindings chapter of the docs and in the function run-context in boot.janet. I don't know if they refer to the same thing.

For the former location, there are at least these two paragraphs:

Dynamic bindings should be used when you want to pass around an implicit, global context, especially when you want to automatically reset the context if an error is raised. Since a dynamic binding is tied to the current fiber, when a fiber exits the context is automatically unset. This is much easier and often more efficient than manually trying to detect errors and unset context.

Dynamic bindings work by a table associated with each fiber, called the fiber environment (often "env" for short). This table can be accessed by all functions in the fiber, so it serves as place to store implicit context.

The first paragraph suggests perhaps somewhere in the source (or may be someone's project?) one might be able to find an instance of "reset the context if an error is raised". May be that would give more clues.

The second paragraph suggests to me that an implicit context can be stored in a table. Perhaps not much of a clue.

For run-context:

janet/src/boot/boot.janet

Lines 2430 to 2449 in 848d4a1

	(defn run-context
	```
	Run a context. This evaluates expressions in an environment,
	and encapsulates the parsing, compilation, and evaluation.
	Returns (in environment :exit-value environment) when complete.
	opts is a table or struct of options. The options are as follows:
	* :chunks - callback to read into a buffer - default is getline
	* :on-parse-error - callback when parsing fails - default is bad-parse
	* :env - the environment to compile against - default is the current env
	* :source - string path of source for better errors - default is "<anonymous>"
	* :on-compile-error - callback when compilation fails - default is bad-compile
	* :evaluator - callback that executes thunks. Signature is (evaluator thunk source env where)
	* :on-status - callback when a value is evaluated - default is debug/stacktrace.
	* :fiber-flags - what flags to wrap the compilation fiber with. Default is :ia.
	* :expander - an optional function that is called on each top level form before being compiled.
	* :parser - provide a custom parser that implements the same interface as Janet's built-in parser.
	* :read - optional function to get the next form, called like (read env source). Overrides all parsing.
	```
	[opts]

The single argument to this function is a table IIUC. So perhaps it is either this table of something within it.

[yumaikas]

As I understand it, fibers are Janet's answer to Lua's coroutines. They allow for cooperative multitasking, as well as providing a flexible abstraction for things like catching errors, or generating infinite sequences.

[uvtc]

Thanks, @sogaiu , thanks @yumaikas . I think I see that fibers are single-threaded, cooperative multi-tasking, where the fiber has some of its very own state (environment) that it keeps track of.

@yumaikas , thanks, though I'm unfamiliar with Lua's coroutines.

[saikyun]

The way I see fibers are the extraction of certain parts of a function from the function.

Specifically:

• local bindings on a stack (when leaving the fiber the bindings defined in the fiber are dropped)
• possibility to “return early”

Being able to leverage these attributes without functions leads to:

• do blocks
• let bindings
• try / catch

So it is an abstraction that extracts useful tools from functions without having to define a function. Iiuc the above can be defined with functions instead, but functions tend to be more opaque, whereas fibers are easier to inspect and simply does less.

[pepe]

I am sorry, but I do not think this is true. Or better not all of it. Actually, to create a fiber with fiber/new, you have to supply a function.

[saikyun]

Oh, I realized now I had confused some parts, apparently do doesn't seem to be using fibers as I thought. :) I thought fibers was related to the scoping rules (i.e. the fiber is the scope), but that seems to be wrong. :) You're right about fiber/new as well, thanks for correcting me.

[pepe]

The simplest mental model which works for me is this:

• fiber is a coroutine.
• fiber can signal its parent fiber through the yield, signal, or error. If it's on the event loop, you can use ev/give-to-supervisor to send a message to its supervisor channel. You can call fiber/new with an optional signal mask.
• each fiber contains an environment table that can be queried for values. You can tell fiber/new how this table should be constructed.
• fiber can be put on the event loop for event multitasking with ev/go. You can call it with optional channel, which becomes the fiber's supervisor channel.
• fiber can be resumed with resume. If it's on the event loop, it is resumed automatically and should not be resumed manually.

It is definitely not everything, but this works for me.

[pepe]

I think I will edit this answer as things come to mind 🤔,

[soomtong]

some systems call it 'green thread', is it right?
like go lang's 'go'

...aha, it is not same. go didnt have a yield or resume.

[uvtc]

Thanks, @saikyun , thanks @pepe . As part of this, I think I was conflating:

• logical thread of execution
• kernel thread (multithreading)

I see that fibers give you a way to get the former (specifically, single-threaded, cooperatively scheduled concurrency), but not the latter.

[pepe]

True. Maybe the very basic would be: any Janet's code running is in the fiber.