Forcing a driver call to use a specific thread

[Jakob Cederlund på UAB]

At 16:57 2001-10-29 +0000, Sean Hinde <Sean.Hinde@REDACTED>wrote:
>Hi,
>
>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 
serialized i/o.)

This too, will be updated in the manual.

Hope this helps
/Jakob