[eeps] Async-Thread Pool Per Port Driver

[Michael Truog]

Currently, it seems hard to use the async thread pool without 
potentially conflicting with other port drivers that also use the async 
thread pool (efile, et al.).  The current solution is to just increase 
the thread count with "+A" on the command line, such that no async 
thread queues get filled with long running jobs.

Is there sufficient interest to make port drivers instantiate their own 
async thread pools, using the same async thread pool code, so that one 
port driver is unable to influence other port drivers directly.  Such a 
change would help encourage the use of the async thread pool to create 
efficient Erlang bindings to C or C++ that can handle longer running 
async thread jobs.

I would hope the driver entry tie-in to an async thread pool would 
provide configuration for the thread count (default perhaps, with a 
string tag that can be referenced on the command line) and might be able 
to configure the stack size limit.

I also see the possibility for an api to the async thread pool improving 
the current hot code update situation.  If you could suspend/restart an 
async thread pool I do not think there would be a reason to lock the 
port driver, making it permanent (blocking it from ever having a hot 
code update).  The async thread pool suspend would need to possibly wait 
for all the jobs to complete while blocking new jobs with a timeout, or 
some similar mechanism.  
(http://www.trapexit.org/forum/viewtopic.php?t=14295&sid=5de3c47e32136682080511d8d95d458e) 


Are there any architectural reasons why this change should not occur?

Thanks,
Michael Truog