[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wip-ports-refactor
From: |
Ludovic Courtès |
Subject: |
Re: wip-ports-refactor |
Date: |
Thu, 14 Apr 2016 16:03:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hi!
Andy Wingo <address@hidden> skribis:
> I have been working on a refactor to ports. The goal is to have a
> better concurrency story. Let me tell that story then get down to the
> details.
In addition to concurrency and thread-safety, I’m very much interested
in the impact of this change on the API (I’ve always found the port API
in C to be really bad), on the flexibility it would provide, and on
performance—‘read-char’ and ‘get-u8’ are currently prohibitively slow!
> Going forward we need to define a Scheme data type for ports, and to
> allow the read/write procedures to be called from Scheme, and to allow
> Scheme implementaitons of those procedures. We also need to figure out
> how to do non-blocking I/O, both on files and non-files; should we set
> all our FD's to O_NONBLOCK? How does it affect our internal
> interfaces? I do not know yet.
I think this part can come later, after the refactoring is done.
> There's still space for different schedulers. I wouldn't want to
> include a scheduler and a thread concept in Guile 2.2.0 I don't think --
> but if we can build it in such a way that it seems natural, on top of
> ports, then it sounds like a good idea.
I agree. If the new implementation gives users more flexibility, then
people will be able to easily experiment with things like 8sync or your
ethreads branch. From there on, we’ll have a better idea of whether a
scheduler framework or something should be added to Guile proper.
I’ll take a look at the code.
Thanks a lot for fearlessly diving into this! :-)
Ludo’.
Re: wip-ports-refactor, Chris Vine, 2016/04/24