The main consideration (right now) is that you need to first call a method called Base.start_reading to trigger Julia to start consuming the data.
The other alternative, is to call while !eof(f); readbytes(nb_available(f)); end in a loop in a Task, and let it handle the async work in the background (with respect to your other running tasks). On Sun, Sep 14, 2014 at 1:00 PM, Dan Luu <dan...@gmail.com> wrote: > Thanks! > > A related question I have is, is there an existing function that acts > like recv/recvmsg/recvmmsg in C (with O_NONBLOCKING), which returns > whatever's available? I was hoping readavailable would do that, but it > blocks if nothing's available, which is why I'm checking nb_available. > > I can see why you'd warn people that the data may not be split the > same way, but in this case I'm ok with receiving partial frames for > whatever the definition of a frame is. > > On Sun, Sep 14, 2014 at 11:17 AM, Jameson Nash <vtjn...@gmail.com> wrote: > > There are two answers here: > > One is that writing the stream does not imply the data is immediately > > readable, or will even be split up the same when received. The second > part, > > is that Julia does not start consuming the data until you start reading > it. > > This is important because you might want to pass this handle to an > external > > process, and not have Julia consume part of the data I the meantime. > > > > > > On Sunday, September 14, 2014, Dan Luu <dan...@gmail.com> wrote: > >> > >> julia> r,_ = redirect_stdout() > >> (Pipe(open, 0 bytes waiting),Pipe(open, 0 bytes waiting)) > >> julia> nb_available(r) > >> 0 > >> julia> println("foo") > >> julia> nb_available(r) > >> 0 > >> julia> println("foo") > >> julia> nb_available(r) > >> 0 > >> julia> readline(r) > >> "foo\n" > >> julia> nb_available(r) > >> 4 > >> > >> Even if there's data available, nb_available returns 0. From the name, > >> I would have expected this function to return the number of bytes > >> available. However, since there's no documentation, either in > >> help(nb_available) or in the code itself, I can't tell if this is a > >> bug or if this is behavior is by design. >