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.
>
