[erlang-questions] Asynchronous port drivers

[Tim Watson]

Hi all,

I'm implementing a port driver for Erlang/OTP12B and I have a
question. I want the driver to be able to process multiple concurrent
requests.

The way I'm dealing with the at the moment, is by responding to a
port_command call in driver_output, unpacking the supplied buffer and
passing it to driver_async along with a funtion to be called from a
thread pool thread. I also pass a callback function to driver_async,
which is getting called after the asynchronous processing takes place.
In this callback function, I'm using driver_send_term to respond to
the calling process.

Here's my question(s):

1. Is the callback function I post to driver_async called from a
thread pool thread or from the main emulator thread!? I'm hoping the
latter.

2. Is it safe to open just one port to the driver and fire multiple
concurrent requests at it using port_command!?

Question 2 is the one I'm really concerned about. From what I can see
in the documentation, port_command is a synchronous call. This is
presumable thread safe on the erlang side (I hope).

I'm planning on spawining a new process per request, letting that
process call port_command and wait using receive for the response
(driver_send_term is being supplied with the calling process' Pid,
which I obtain within the driver_output callback using the
driver_caller api call).

Is this approach a safe one!? I ask only because I've noticed other
people trying to implement production quality linked-in drivers are
using a combination of driver_outputv and the driver queue (with it's
delightful ErlIOVec and SysIOVec consuming functions) to deal with
asynchronous requests. This approach looks complicated and (I'm
guessing) makes writing portable code harder, from what I can see.

Any assistance would be greatly appreciated!

Thanks,

Tim Watson