Almost every time I've created a custom input port, I've run up against the rule: "The read-in procedure must not block indefinitely." And each time, I've either:
- ignored it (with the suspicion that I've just written code that can block the whole process, though I've never actually verified this); - written a state machine that buffers data from the underlying port until it has enough to work with; or - created a new thread that reads from the underlying port and pipes data back. (By the way, `filter-read-input-port` doesn't help here, since the filter is called in the context of the above-mentioned `read-in` procedure, so, even though the docs don't mention it, presumably it shouldn't do blocking I/O either.) The last of these is the least painful (if you count the psychological pain of option 1), but it raises another problem. If the data turns out to be malformed, I want to raise an exception. (Or, at least, I think I do.) But I want to raise it in the reader's thread, and I don't think there's a way to do this, short of an explicit pre-arrangement. Has anyone else dealt with this problem (and come up with a nice solution)? I haven't yet tried using generators. They might make it a bit easier to do a variation on option 2, at the cost of a bunch of stack-copying. - Jon -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
