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 <zelphirkaltst...@posteo.de> 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 >
