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