[erlang-questions] : ready_async() before outputv() calling driver_async() completes?

[Raimo Niskanen]

In-line answers below.

In which driver do you see that ready_async() happens before
outputv() returned? And how do you see it?

The file driver (efile_drv) has a strange optimization
where it short circuits driver_async() for simple file
operations, so it itself calls ready_async() from
within the outputv() call.

If it happens in some other driver that does not do
the same kind of dirty tricks; it is a bug.



On Thu, Oct 16, 2008 at 06:45:17AM -0500, Paul Fisher wrote:
> Raimo Niskanen wrote:
> > On Wed, Oct 15, 2008 at 06:08:31PM -0500, Paul Fisher wrote:
> >> Should it be possible for a ready_async() callback to happen before the
> >> outputv() callback which called driver_async() has returned?  I am
> >> seeing this happen on R12B-2 smp runtime (2 schedulers), w/four (4)
> >> async threads.
> > 
> > And even if the SMP emulator does not do it explicitly,
> > it is always possible for the thread calling outputv()
> > to get scheduled out between the return from driver_async()
> > and the return from outputv(), and the asynchronous
> > thread to get scheduled in, do its thing and call ready_async()
> > right then.

Forget I said that, I was writing before thinking.

Of course we have locks preventing this to happen
so drivers can happily behave as before the SMP era.

> 
> I am talking about SMP with async threads only.
> 

OK, SMP 2 schedulers 4 async threads. I am with you now...

> The documentation says that the ready_async() callback happens from the 
> emulator thread.
> 
> "This function is called from the erlang emulator thread, as opposed to 
> the asynchronous function, which is called in some thread (if 
> multithreading is enabled)."
> 
> 
> All other indications in the documentation make me believe that only one 
> callback from an emulator thread is active in a callback at a time (for 
> each port instance that is).

Correct.

The default for a driver is that it gets one lock and any callback
except for the driver_async callbacks all use the same lock.
Hence only one callback at a time in the whole driver is
executed. This is a fallback to make old non-SMP aware drivers
work as before.

> 
> "There will only be one thread at a time calling driver call-backs 
> corresponding to the same port, though."

Drivers that so desire can by setting a flag in their 
driver structure during driver init request port locking.
Then they get one lock per port and can only execute in one
callback per port, but several ports can execute callbacks
in parallel.

The most important drivers within OTP has been rewritten to use
this feature, but many less used ones use driver locking.

> 
> 
> So you are saying that ready_async() is an exception to this?

No, sorry about the noise.

> 
> 
> --
> paul
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB