[erlang-questions] driver_create_port overhead and driver_caller

[Tim Watson]

On 14 Jun 2013, at 11:19, QDev wrote:

> Is there any advice from OTP team on best way to handle long running task in driver that needs to do ongoing communication with peer Erlang process? Can Erlang process calls outputv and use mutex to talk to async thread (or manual spawned thread) be best?

I've seen driver code that worked that way which was pretty efficient.

> Is locking in outpuv not risk to schedulers if outputv take too long, like with NIF calls?

If I understand it correctly, yes, this is a risk. Use the async thread pool or pool/spawn your own threads to compensate.

> Is there other way - would it be better in outputv to put binary/ErlIOVec directly in driver queue with driver_enqv or driver_enq_bin but then port data lock has to be use to synchronise reads/writes to driver queue anyway. That means more contention if many concurrent threads are working no? So I was thinking better to use mutex per long running thread instead.

I've not used the driver queue much in the past, so not sure about that.

> Also, is it considered necessary to pool worker thread manually? In previous releases, using async thread pool could have detrimental effect on I/O performance - is this still the case?

ISTR reading that the async threads used by drivers are now separate from those used by the I/O drv internally.

Cheers,
Tim