[erlang-questions] : : : : driver_entry stop() and driver_async() interaction

[Paul Fisher]

Chris Newcombe wrote:
>> We plan while fixing the bug with async_free() mentioned below
>> to introduce a reference counter of async jobs so it will be
>> guaranteed that stop() is not called until all async jobs are done.

Having this as the default model is the right thing to do, since it is 
the safest.  Thank you for including this in the R13 plan.


> Excellent.  But please could you provide APIs to increment and
> decrement that reference count, so that drivers that implement their
> own private thread-pools can achieve the same behaviour?
> 
> Also, I hate to cause feature creep, but if you do implement the above
> reference count/delayed 'stop', please could you also add an optional
> "prepare to stop" callback, which the VM calls when the Erlang code
> closes the port (e.g. the port owner process dies, or something
> explicitly closes the port)?  Some drivers often have fairly
> long-running operations (seconds/minutes) running in their own
> threads, and would like timely notification that they should force
> such jobs to terminate, to allow "stop" to be called as soon as
> possible (the berkeley_db driver has to do this).  i.e. It's not
> always the case that running async jobs should be left to complete in
> their own sweet time.  (Note that this is different from 'cancelling'
> pending-but-not-yet-started jobs.)
> 
> Rationale:  It does actually matter a lot to some drivers that "stop"
> is called as quickly as possible (and completes as quickly as
> possible) after the Erlang side closes the port.  Very often, the
> driver is being stopped because the port-owner is being restarted by a
> supervisor, so another driver instance will be created almost
> immediately.

I would second this.  We have long-running work that could be shutdown 
if we had a signal of termination intent.


--
paul