Port behaving weird

Questions / Help
1

I have a problem with a port program I wrote.

I use Cure to communicate with the port, but the basic settings are:

  • binary
  • {packet, 2}
  • use_stdio

I had an elixir program as the port executable for easy integration with my main application. It would simply pretend to have executed any command I send and give the appropriate response.

In this program I observed lots of weird behavior, like IO.read(2) returning the whole message the port just wrote instead of just 2 bytes of it.

So I replaced it with this:

cat >&2```

I use this as my test executable and observe the same: The first message is written on the stderr (which is unbuffered so I see it immediately) and the second message I'm trying to send never comes through. I also changed for this one `{packet, 2}`into `{line, 256}`to no avail.

Both messages are issued with `Port.command`. Second one always blocks forever. 

Is this a port driver issue?
1 Like
2

Hello.

I found the reason why it blocks.

In all likelihood this happens because I invoke it in a GenServer inside a sync call. Apparently some deadlock…

1 Like
3

That would sound like it, even port responses and commands are sent via messages so if you are blocked on another message then that could happen. :slight_smile:

Showing a reproducible test-case can help, and in the process of simplifying it the bug often appears on its own too. :slight_smile:

4

You’re of course right. :slight_smile:

Cure library and ports were totally uninvolved in the end. I gave a function to execute to a GenServer which sync-called into the same GenServer. That deadlocked.

5

Good news - since 1.3 GenServer.call/3 will raise if you try to call yourself. Time to update! :stuck_out_tongue:

1 Like
6

Hello, Michal.

Yes it is! But you know how it is… once you’ve rolled out a version over the IT infrastructure, you are stuck with it for a while. :wink: