run-fibers with #:drain #t does not wait for dependent threads about fibers

[amirouche]

I think in general it's hard to have a general definition of what it means to be done. scheduler-work-pending?

My idea to workaround the above behavior was the change the definitions of scheduler-work-pending? to with another clause in the and that looks like (zero? (scheduler-waiting-thread scheduler)) where scheduler-waiting-thread is a count of threads that are blocked inside get-message or put-message.

scheduler-work-pending? has the advantage that it's a simple and clear definition, but it is not universal. If you need another definition of "done", for example your definition above, you need to arrange to have the initial fiber outlast the tasks you are concerned with.

That is what I documented in the previous comment.

Thanks for the feedback! 👍

[amirouche]

That said, for my usecase, run-fibers does not return, so this issue does not show up.

There is a workaround where one can properly manage the life of the threads created with call-with-new-thread and wait for the count of threads to become zero in the init procedure of run-fiber.

[amirouche]

Maybe a parent-thread-scheduler parameter can help to solve the issue.

[wingo]

run-fibers #:drain? #t means to run until schedule-work-pending? returns false. scheduler-work-pending? returns true if there are pending timeouts or pending runnable tasks. Neither is the case for fibers waiting on external events; in this case messages on channels. From the point of view of scheduler-work-pending?, this program is undistinguishable from:

(define (main)
  (spawn-fiber (lambda () (get-message channel))))

I think in general it's hard to have a general definition of what it means to be done. scheduler-work-pending? has the advantage that it's a simple and clear definition, but it is not universal. If you need another definition of "done", for example your definition above, you need to arrange to have the initial fiber outlast the tasks you are concerned with.