| This particular customer has 3 (I think, it is more than 1 anyway) shareable
libraries that use RTR. An application can be linked against more than 1.
Thus we also have the problem of shareable libraries affecting each other.
This makes your suggestion harder to use :-)
I think that the only workable solution is to use a RTR wrapper that everybody
use. This package would have knowledge about all channels. I am thinking about
such a package.
A complicating issue is the need to prevent rtr_receive_message against
channels that just got an "accepted" message. This until the DB commit is
complete. Adding a channel to an already active rtr_receive_message is not
possible. Using a 10ms timeout on the receive, and rebuilding the rcvchan
argument may be a way. It is not elegant!
A package like this probably need something like
open channel with an argument to specify a routine to be called when a message
arrives. The callback routine will have the message buffer as
one of its arguments. The callback need to return a value that
tells the package if it is allowed to issue a new read on the
channel or not. The package will not do any
rtr_receive_message calls until the callback returns. On return
from the callback a new receive_message will be issued,
possibly excluding this channel.
free_buffer a routine that returns the message buffer to the package (as an
optimization, the received message callback may return a value
to indicate if the buffer is free)
db_commit_complete a routine to tell the package that a rtr_receive_message is
allowed on a channel. This might be merged with the free_buffer
function. Having them separate allows a bit more freedom with
buffer management.
The package also have to provide a way to invoke all the other rtr functions,
if they are not called directly...
Olof
|