Hi! Summarizing my reply over IRC:
On Thu 07 Apr 2016 06:16, Christopher Allan Webber <cweb...@dustycloud.org> writes: > So, does this branch replace ethreads, or compliment it? Where should I > be focusing my (currently limited) review / integration attempt energy? > I've been hoping to review ethreads this week but now I'm unsure. Can > you explain how the efforts currently relate? This branch hopes to make the "eports" part of that branch unnecessary. However actually implementing user-space threads à la ethreads is out of scope, as is the epoll wrapper. > One other question is if this will help in the "no nice way to do custom > binary ports" stuff that was blocking the > tls-enabled-ports-in-guile-proper thing... Was that the blocker? Anyway the current branch's ports are verrrrrrrry close to R6RS binary ports, so this shouldn't be a difficulty any more. I haven't implemented custom binary I/O ports (we have input-only and output-only but not both) yet, but it should be doable. > As I've said, I'm not tied to 8sync specifically if doing something more > internally makes more sense. (Even if I have a nice site and logo > coming together now ;)) I think keep rolling with 8sync :) It has a nice brand, it's filling a need that probably won't be filled in 2.2.0, it's laying groundwork for future Guile features. Eventually I would like user-space threads in Guile proper, implemented in terms of delimited continuations, and that implies a scheduler too. But that's a bit far off. My goal is to make it possible to add such a thing during the 2.2.x series, probably first as a library (8sync) and eventually as a core Guile feature. Andy
