[erlang-questions] driver_create_port overhead and driver_caller

[QDev]

I have linked in driver which deals with embedded library, can make calls some in outputv, some using driver_async, but now have to support some other long running operations requiring thread affinity and (more importantly) need to receive multiple commands/actions from Erlang client code associated with long running transaction in library API. Currently considering to spawn (or pool) some new thread for these (long running tasks) and using ErlDrvMutex and simple queue/array data structure to communicate with it from outputv, but there is also affinity between Erlang callers process id and long running task thread (since caller originates with erlang:send/2 direct to port, which is accessed via ets table), because replies are sent via driver_send_term so need to also store client's process id in ErlDrvTermData and use driver_monitor_process to ensure that if client dies, work is rolled back. IIRC driver_caller not thread safe, so need to only use this in outputv is that still correct?

Now, just getting used to driver API changes in R16 (haven't written driver since R13B) and have seen driver_create_port. This seems to create new port running driver code, so wonder if this is better approach for these long running tasks, and what are benefits/advantage of doing this?

Thanks
QD