Re: wip-ports-refactor

[Andy Wingo <wingo@pobox.com>]

Hi!

Summarizing my reply over IRC:

On Thu 07 Apr 2016 06:16, Christopher Allan Webber <cwebber@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