Channels and printing in runtime evaluation

[pyrmont]

Description
Using a channel for print operations in runtime evaluation results in strange behaviour.

Steps to Reproduce

1. Run this code.

   (def c (ev/chan))
   
   (ev/spawn
     (while (def v (ev/take c))))
   
   (defn print-to-chan [x]
     (ev/give c x))
   
   (setdyn :out print-to-chan)
   (def res
     (eval-string
       "(defn x []
          (pp :foo)
          (pp :bar)
          :qux)
        (x)"))
   (ev/chan-close c)
   (setdyn :out nil)
   (print "Result is " res)

Expected Result
The code outputsResult is qux.

Actual Result
The actual output on my Mac is for the string Result is to appear.

Notes
This is an intentionally contrived example that tries to simplify the problem to its maximum extent. The context in which I came across this is in developing my own evaluation environment for a REPL project I’m working on.

[sogaiu]

FWIW, I got the same result on a Linux box.

[bakpakin]

The issue here is that the event loop is never yielded to. eval-string basically stop executing after the first call to (pp).

With the following modification for print-to-chan, what's happening becomes a bit more clear.

(defn print-to-chan [x]
  (xprintf stdout "pp %v" x)
  (ev/give c x))

This prints:

pp @":foo\n"
Result is 

[bakpakin]

Notably, this problem will go away if you increase the channel capacity to something like 1000 such that ev/give does not try to yield to the event loop. Unfortunately, you can't yield to the event loop inside the callback for :out.

Not sure what the best solution here is for our use case, it's unlikely that we will be able to just make this work, but perhaps we could raise a better error message.

[pyrmont]

@bakpakin Thanks for adding the error!

After more experimentation, I suspected what was happening was Janet not liking an await to happen inside the cfun_io_print_impl_x function.

What I really want in my particular use case is to guarantee there's never an await when I 'print' to my remote client (i.e. have a blocking write to a TCP socket). I don't believe there's a way to do that at the moment because net/write is simply non-blocking. I had two ideas about what to do:

1. add a new function in net.c that would be a blocking version of net/write (or add another optional parameter to net/write to enable blocking behaviour)

2. modify file/open to allow a JanetStream object to be given so that you can use file/write when you want blocking behaviour (I don't know if this is workable on Windows)

Are you amenable to either approach? Happy to work on a PR.

[bakpakin]

For netrepl, we use a buffer instead of a print function, and then spawn a fiber than continuously writes that buffer to a socket. Care should be taken to avoid a busy loop and 100% cpu usage.

Another alternative is make a very large capacity for the channel, and try to detect overflow before giving to the channel.

[pyrmont]

A variation on Option 1 would be to switch on 0 (or false) as the timeout value in net/write and have this result in an alternate code path that calls a blocking write.

[pyrmont]

For netrepl, we use a buffer instead of a print function, and then spawn a fiber than continuously writes that buffer to a socket. Care should be taken to avoid a busy loop and 100% cpu usage.

Yeah, this is what I'm doing now too. The problem is that I don't get any data sent to the client until the evaluating fiber suspends (or finishes evaluating) and the buffer has a chance to be flushed. The experience would be nicer if the writes simply happened at the time the print function was called, like they would if printing to stdout.

[bakpakin]

I'm partial to adding a function for converting a stream to a file for synchronous IO. Whether or not it should be wrapped up in file/open is another question, but I would think something like ev/to-file would make more sense as a wrapper around fdopen