Re: Guile fibers return values

[Zelphir Kaltstahl]

Thank you for the detailed explanation!

By "process" I meant only "sequence of steps performed", the main thunk
in run-fibers, separate from the steps that are run in the spawned
fiber, not really OS process or thread.

I will take a look again at the parallel forms and think about whether I
want to use them or fibers.

Originally I had my algorithm in Racket and could not get it to work in
parallel, unless I explore places and serializable lambdas more.

I think fibers are more flexible than the parallel forms though, as one
could also build a pipeline using fibers or any kind of network of
connected computation tasks, while the parallel forms split a task
immediately and then join again. Not sure any of the additional
flexibility of fibers helps me. Perhaps I can use both and abstract from
it with an additional abstraction layer. Then my code could also be used
more easily in other Schemes.

This is my project:
https://notabug.org/ZelphirKaltstahl/guile-ml/src/wip-port-to-guile

I still am not sure though, if I can simply use any lambda I want and
send that to a fiber, or I need to look out for things like "What is in
the environment of the lambda?". It would be good to know that. I guess
it depends on how data sent on channels is handled in the fibers library.

Regards,

Zelphir

On 1/5/20 1:33 PM, Chris Vine wrote:
> On Sun, 5 Jan 2020 02:30:06 +0100
> Zelphir Kaltstahl <address@hidden> wrote:
> [snip]
>> This way of communication between the fiber and the main process seems
>> in the style of Racket's places. Except that I can send normal
>> procedures / lambdas to the fiber, which is great on a single machine,
>> while I need to send serializable lambdas to Racket places (and I have
>> not gotten to do that yet).
>>
>> Is there a restriction on the kind of lambdas I can send on a channel as
>> I did in the example above?
> I may well be missing your point, mainly because I don't know what you
> mean by "the main process" - all the fibers are part of the same
> process, and can be run in the same native thread if you want.
>
> run-fibers runs what amounts to a scheduler and does not return until
> the thunk passed to it returns.  So if by "the main proccess" you mean
> the thunk which is running on a fiber scheduler, then you know it has
> finished when run-fibers returns, after which you can execute what
> other non-fiber code you want to execute.  run-fibers will return the
> value (if any) returned by the thunk which it runs.
>
> Within the thunk run by run-fibers, you normally synchronize using
> channels. At it's absolute simplest it can be this:
>
>   (display (run-fibers
>             (lambda ()
>               (let ((channel (make-channel)))
>                 (spawn-fiber
>                  (lambda ()
>                    (sleep 1) ;; do some work
>                    (put-message channel "hello world")))
>                 (simple-format #t "~a~%" (get-message channel))
>                 "finished\n"))))
>
> Here the "main" thunk (the one passed to run-fibers which returns
> "finished\n") will not finish until the fiber thunk has finished,
> because of the wait on the channel.  If you spawn multiple fibers and
> the "main" thunk does not wait for the fibers like this, and you
> therefore need to ensure additionally that run-fibers does not return
> until all the fiber thunks have finished, you can set the drain
> argument of run-fibers to #t.  Probably in that case your "main" thunk
> will not return a meaningful value.
>
> You say you want "to parallelize some algorithm".  If that is your main
> aim, consider guile's parallel forms of parallel, let-par and friends.
>
> Chris
>