@mflatt Can you explain this to me? ;; FIXME: When Racket's "green" threads are implemented, ;; this lock acquire will need to cooperate, so that other ;; green therads can run if the lock cannot be acquired (define (lock-acquire lock) (mutex-acquire lock))

Racket’s thread will not be the same as Chez’s thread; instead, it will be more like Chez’s engines

When a Racket thread is blocked on a lock, then other Racket threads in the same Chez thread should be able to procede

I’ve just started looking at the implementation of Racket’s thread in terms of continuations and timers

Okay, yeah I have started on an implementation of racket’s thread on top of chez engines. And am thinking about implementing a scheduler for them (also using engines) but am not sure how engines interact with locks and regular threads

And htought maybe the cooperative lock concept applied here.

It turns out that there are problems with using Chez engines directly. Notably, dynamic-wind winders are run when an engine pauses and resumes.

I imagined providing a Chez-like engine interface from core and then implementing threads+events+custodians in Racket

@samth. this probably interests you too

The core would also need to export hooks to support locks, and I’m not sure exactly what that should look like

The dynamic-wind problem sounds like it would impact a direct use of continuations as well, though

It would be simpler to implement threads+events+custodians in core, but I much prefer writing Racket code, and for the sake of furture portability I’d prefer to implement things in more layers if possible

But maybe I’m thinking about this incorrectly

@samth Yes, by “continuations” I really mean “metacontinuations” in the new "http://core-control.ss\|core-control.ss", which can easily support a metacontinuation swap that doesn’t run winders

@mflatt are you in boston already?

No, I’m about to go to the airport

Ok

we should talk about coordinating our efforts, but maybe Boston is the best time to do that