[erlang-questions] Asynchronous port drivers
Fri Mar 7 04:46:57 CET 2008
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
All callbacks are always executed synchronously from the main emulator
> 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.
More information about the erlang-questions