Forcing a driver call to use a specific thread
Jakob Cederlund på UAB
Tue Oct 30 11:47:44 CET 2001
At 16:57 2001-10-29 +0000, Sean Hinde <Sean.Hinde@REDACTED>wrote:
>First off thanks to the OTP team for providing some very nice documenation
>to help driver writers :)
Thank you, thank you! It's not perfect but it's better than no
documentation at all. The driver interface in R8 was a moving target when
we wrote it so some things work better than the documentation says. The key
parameter in driver_async does indeed work; the efile driver depends on it.
This section in the documentation is totally false: (it has been true, but
it's not in R8)
>"If there is a thread pool available, a thread will be used. A specific
>instance of the driver always uses the same thread. If that thread is
>already working, the calls will be queued up and executed in order. Using
>the same thread for each driver instance ensures that the calls will be
>made in sequence."
The truth is that the key parameter controls the thread used; for the same
value of *key, the same thread will be used. To mimic the behaviour
described in the documentation do this: driver_async(myPort, (unsigned
int*)&myPort, myAsyncFunc, myData)
If key is left to NULL, every asynchronous call will be round-robin scheduled
in the thread pool, which may result in to calls to the same driver
executing in parallell or even opposite order.
(I thought the original behaviour was better, but the efile driver uses the
file descriptor as key, so that two fdopen on the same descriptor will have
This too, will be updated in the manual.
Hope this helps
More information about the erlang-questions