[erlang-questions] Asynchronous port drivers

[Serge Aleynikov]

Tim Watson wrote:
> 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.

All callbacks are always executed synchronously from the main emulator 
thread(s).

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

I assume you are talking about running emulator with SMP mode enabled. 
In this case the driver_entry's callback corresponding to port_call may 
obviously be called from different emulator's threads.  However, since 
the driver_entry's callbacks (including (*call)(...)) are synchronized 
access to the driver should be thread-safe.

> 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!? 

Indeed, and likely being more efficient as it avoids extra copying of data.

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

Perhaps someone else could comment on this, but it looks like the driver 
design went through several stages of refactoring and multiple 
data-passing interfaces are perhaps artifacts of backward-compatibility.

Serge