[eeps] Activity

[Michael Truog]

I am not sure if an EEP is best for these suggestions.  They relate to the
Erlang VM implementation, rather than language features.

I really would like to be able to use the asynchronous thread pool to avoid
preempting the Erlang VM with an external thread pool
(caused by the kernel OS scheduler).
However, there are some problems:

1) All Erlang code uses one asynchronous thread pool with separate job
queues. So, any long running jobs submitted to the asynchronous thread
pool will clog up the thread pool eventually. You can make the thread
pool very large, but that does not solve the problem. There should be a
way to partition the thread pool so that separate code will not impact
each other. The QoS from the usage of the thread pool should be more
deterministic then.
2) Usage of an asynchronous call in a port driver automatically locks
the library so it can not be hotswapped, which is safe. However, it
would be nice to be able to have a way of unlocking the library that is
non-blocking.  It seems easy to count the async calls originating from a
specific driver and only allow an unlock/unload if the count is 0.

These issues may not be regarded by many people as important. However,
I think their impact would be large as machines grow in capacity. I
also am very disappointed by the chance that something like the file
module might conflict with unrelated usage of the asynchronous thread
pool in unrelated processes (there is an environment variable to change
this, but that type of solution is adhoc). Please consider this as a
possible improvement.

Thanks,
Michael Truog