On 2014-06-15 3:40 AM, Matthew Flatt wrote: > [(queue-empty? ports) > (cond > [(zero? (random 100)) > (suspend) > (retry)] > [else 0])] > > and that's obviously a hack, but it should illustrate that regexp > matching can be happy to work with the bytes that it has been given --- > if a port properly reports that no more bytes are available.
I tried something like this, returning 0 on the *first* call if no more bytes were immediately available, and only then blocking to wait for more. But the regex code insists :-) (by calling repeatedly until it... gets bored?) Hm, that gives me an idea though: since I have a whole thread already set up, nothing stops me from sending a signal and then issuing zeroes repeatedly until the other thread gets back to me with more input. Hmm. > I'm not sure I understand your overall goal, but it seems like you're > tying to implement `read-json-evt` in terms of `read-json`, or more > generally implement R`-evt` in terms of R. Is there a reason you can't > just call R in a separate thread and wrap that attempt up as an event? That's not quite it: it's for when I have some blocking, recursive-descent style input-parsing procedure (e.g. read-json, or parsing an HTTP request, etc etc etc) that I want to feed input to incrementally as it arrives. So I can reuse these thread-style readers when I myself am working in event-driven style. An approximation to what I want could be to thread-wrap read-json reading from a pipe and write or copy-port each segment as it appears; the code I wrote attempts to avoid the need for the redundant copying. But it seems difficult to get right, so maybe using a pipe to feed the blocking reader is better. > I also suspect that you want a poll operation that reliably fails if > progress is not possible until something more is done externally. > Racket's concurrency system supports that concept; see > `poll-guard-evt`. Thanks, I'll check that out! Regards, Tony _________________________ Racket Developers list: http://lists.racket-lang.org/dev
