[racket-dev] regexp.c and lookahead

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