# Avoiding \`readavailable()\` when communicating with long-lived external program

**URL:** https://discourse.julialang.org/t/avoiding-readavailable-when-communicating-with-long-lived-external-program/61611
**Category:** General Usage
**Tags:** question, review, ipc
**Created:** [May 21, 2021, 10:48pm UTC](https://discourse.julialang.org/t/avoiding-readavailable-when-communicating-with-long-lived-external-program/61611 "2021-05-21T22:48:32Z")
**Posts on this page:** 1
**Showing post:** 16

<div class="post-metadata">

### Author: ![MA\_Laforge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ma_laforge/32/385_2.png) [@MA\_Laforge](https://discourse.julialang.org/u/MA_Laforge)
#### Post date: [May 24, 2021, 2:36am UTC](https://discourse.julialang.org/t/avoiding-readavailable-when-communicating-with-long-lived-external-program/61611/16 "2021-05-24T02:36:59Z")

</div>

### RE: `readavailable()`

I have recently encountered a problem with `readavailable()` myself. When I used the following, I noticed only a part of my file was read in:

```julia-auto
f = open("myimg.png")
data = readavailable(f) #Only reads part of the file?!?
close(f)

```

On the other hand, if I simply used `read()`, the whole image was read in from disk:

```julia-auto
f = open("myimg.png")
data = read(f) #This time, I get the whole file!
close(f)

```

So, maybe this is why there is a warning in the julia documentation:

> [@Julia documentation](#):
>
> […] Read available buffered data from a stream […]

You only get whatever your OS chooses to read (cache) into your buffer.

### Possible limitation wrt `Pipes`?

I’m not 100% sure this statement applies to `Pipe`-s, though. They might react differently to the `readavailable()` command than `IOBuffer`-s do. In fact, I have observed they react differently in certain ways wrt their blocking behaviour - as mentioned in my previous post.

---

_[View the full topic](https://discourse.julialang.org/t/avoiding-readavailable-when-communicating-with-long-lived-external-program/61611)._