On 2021-05-06 19:07, Marc Feeley - feeley at iro.umontreal.ca wrote: >> On May 6, 2021, at 10:49 AM, Amirouche <xxxxxx@hyper.dev> wrote: >> >> >> On 2021-05-06 16:26, Marc Feeley - feeley at iro.umontreal.ca wrote: >>> I’m not sure what your goal is with this SRFI. Could you clarify? >>> SRFI-18 (Multithreading support) is supported by many Scheme >>> implementations and is the best thread API if you are interested in >>> portability accross Scheme implementations. It seems some of the >>> things you are proposing have a direct link with SRFI-18 features, so >>> I don’t understand why a new SRFI is needed. >> >> So far, if we disregard PRIORITY, coop is only an alternative to >> SRFI-18. >> >> When priority is +inf.0 it should have exclusive access to a CPU. >> Otherwise it is a hint to implement fairness. > > Have you looked at SRFI-21, which adds priorities to SRFI-18? Now I do. That is Gambit thread API :) > Note that few Scheme systems implement SRFI-21 because priorities > require a carefully designed thread scheduler (as far as I know > only Gambit implements SRFI-21). > So I doubt the priorities of coop can be implemented portably. (coop-spawn +inf.0 thunk) can be implemented by forking a POSIX thread, and setting the priority of the POSIX thread with setpriority with some coordination between the various flow, it is doable to achieve sort-of "dedicated computation unit" still the scheduler is implemented in OS kernel outside most Scheme implementation and full control is not possible. priorities are marked as a hint. In my implementation only priority of +inf.0 is sort-of implemented, other priorities are no-op. When I added priorities I had Gambit API in mind (SRFI-21), so that Scheme move toward that kind of control. > If channels are an important feature of coop Channels are essential to coop. The first draft did not include coop-spawn and priorities. I am even wondering if I should not remove coop-spawn. But without coop-spawn it is much more difficult to implement portable libraries or programs. Basically (coop-spawn thunk) is SRFI-18 (make-thread thunk), and (coop-spawn +inf.0 thunk) is (make-thread (lambda () (thread-priority! 8) (thunk))). But, in cases such as Cyclone that has no green threads, there is the choice to use the current thread or fork a POSIX thread to host the flow (depending on the priority). No Scheme implement Gambit advanced scheduler. Gambit scheduler will migrate the equivalent of flows across cores almost anytime depending on the load. coop is not competing with Gambit, or SRFI-18 or SRFI-21 or even Termite. Even if it is left unspecified in coop, there is no other Scheme but Gambit, that can serialize a continuation and migrate it to another machine over the network, possibly hosted by nodejs, and compile the code on the fly or hot reload it... > please try to see if “mailboxes” can be used instead. If "mailboxes" are buffered, they can not be used in place of channels. Coop channels are unbuffered, and they only make sens with the associated coop-wrap, coop-consume, coop-produce, coop-sleep and coop-apply. > They are implemented by several > Scheme implementations that support SRFI-18. Here’s a simple example > with Gambit (should also work as-is with Racket): I did not look at Racket, so far I have in mind Cyclone, Chez, Gambit, and possibly Guile. > > (define t (thread > (lambda () > (let loop () > (let ((m (thread-receive))) (thread-send (car m) > (sqrt (cadr m)))) > (loop))))) > > (thread-send t (list (current-thread) 10)) ;; request sqrt of 10 > > (thread-receive) ;; => 3.1622776601683795 > thread-receive and thread-send have an SRFI?
