coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 05 May 2021 18:30 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 10:28 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Feeley 06 May 2021 14:26 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 14:49 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Alexey Abramov 06 May 2021 15:32 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 06 May 2021 15:41 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 16:28 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 06 May 2021 16:37 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 16:48 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 06 May 2021 17:22 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Wolfgang Corcoran-Mathe 06 May 2021 19:12 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 06 May 2021 19:37 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Wolfgang Corcoran-Mathe 06 May 2021 21:54 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 07 May 2021 07:01 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Alex Shinn 07 May 2021 07:41 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 07 May 2021 08:35 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Alex Shinn 07 May 2021 08:41 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Nieper-Wißkirchen 07 May 2021 08:58 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Alex Shinn 07 May 2021 13:47 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 19:36 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Lassi Kortela 06 May 2021 19:40 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche Boubekki 06 May 2021 21:25 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Marc Feeley 06 May 2021 17:07 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 21:01 UTC
Re: coop - a concurrent ml-like wanna be (pre-SRFI) John Cowan 06 May 2021 21:25 UTC

Re: coop - a concurrent ml-like wanna be (pre-SRFI) Amirouche 06 May 2021 21:01 UTC

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?