@mflatt I’ve thought about possibility, but it seems difficult, because I don’t think we want to expose pthreads directly to the “thread” layer

currently, the minimum set of features that @spall has used is: creating chez threads, chez-level locking, chez-level condition variables, and some access to information about currently-running chez-level threads

That sounds appropriate to me, especially if it’s functionality that any runtime system would have to include to support futures, similar to the way the core provides an engine API to implement threads at the “thread” layer

How hard is it intended to be to change the API provided by the core to the various linklet-implemented layers?

for example, the Chez condition variable API is a bit odd, I think, and might not be what we want for some other runtime

but it’s hard to be sure now, and so the easiest thing is to just expose it directly instead of abstracting prematurely

If it’s going to be problematic to change, though, then we should figure out a reasonable abstraction ahead of time

I don’t think that needs to be an especially stable API

>currently, the minimum set of features that @spall has used is: creating chez threads, chez-level locking, chez-level condition variables

Additionally, the 2 primitives chez provides. And

exposing pthreads would also make it potentially-possible to implement places at the “thread” layer

It sounds to me like this conversation is suggesting we move futures to the thread layer?

@spall yes

Alright I will start on that then.

We can talk at our scheduled meeting today about plans for that

ok

does racket have a form like meta-cond?

or will racket always be “threaded”?

pthreaded i mean

@spall Racket will always have access to those primtives, but the “cs” layer will have tohave fake definitions when not threaded

ah ok thanks