From: Nikodemus S. <nik...@ra...> - 2009-12-18 17:24:02
|
2009/12/18 Nathan Froyd <fr...@gm...>: > We should get a better SERVE-EVENT story together (I didn't notice a > lot of discussion on fu-streams on the whiteboard :) ). What did you > have in mind for playing nicely with FD-HANDLERs? Do you mean that > things should fall back on FD-HANDLERS if threads aren't available? We actually had the obligatory DIE-FD-STREAMS-DIE! session (with limited participation) in the workshop. My notes from there, best read in org-mode: * Da IO Plan *** Can we do this in stages? *** IO API can be done before and FD streams transplanted on top of that. (Device layer, buffering) *** FILE-STREAM on top of device layer (FILE-STREAM should not be a subclass of FD-STREAM) *** ANSI stream changes belong here? *** SB-BSD-SOCKET streams on top of device layer. *** Locks on streams (kill sessions) ***** This needs to get rid of double-buffering first. ***** Needs to happen mostly pretty high up -- "ansi" layer mostly? ***** OpenMCL design seems nice. Maybe an assertion mode as well -- but that could be icing. *** Later ***** Raw vector IO (floats, round-tripping fixnums, etc) ***** string-stream like stuff for bytes ***** Newline conventions ***** byte order stuff ***** serialization contrib The consensus was that (1) trying to replace fd-streams and serve-event in one go is mostly doomed to fail, so it has to be done one step at a time (2) simple-streams can serve as design basis, but no need to try to follow the API 1:1 (3) serve-event needs to die: streams implementation should have sufficient hooks and multiplexing facifilites for writing your own event-loop. Cheers, -- Nikodemus |