Hi! Andy Wingo <wi...@pobox.com> 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’.
