Implementing callback for SendHandle::collect

Hello,
There's currently a possibility to add a callback to an InputPort such as a
method is called when a new data arrives. I would like to have the same
possibility for an OperationCaller. My goal is to implement a timeout on
operation calls. There's currently two way to get the execution status: one
blocking using collect() and one non-blocking using collectIfDone(). The
blocking collect() isn't an option for me since this would block my thread
and I can't configure a timeout. The non-blocking collectIfDone is a working
option but this is not scalable because I have to periodically poll each
SendHandle to get it's status. Indeed, I would like to be able to send
multiple operations and be notified as as soon as the results arrive.

After looking in the code, I saw that the blocking is in fact done directly
in the DataSource. I'm not sure how to implement this. Any suggestions?

Thank you,

Philippe

Implementing callback for SendHandle::collect

On Tue, Jul 5, 2011 at 4:32 PM, Philippe Hamelin
<philippe [dot] hamelin [..] ...> wrote:
> Hello,
> There's currently a possibility to add a callback to an InputPort such as a
> method is called when a new data arrives. I would like to have the same
> possibility for an OperationCaller. My goal is to implement a timeout on
> operation calls. There's currently two way to get the execution status: one
> blocking using collect() and one non-blocking using collectIfDone(). The
> blocking collect() isn't an option for me since this would block my thread
> and I can't configure a timeout. The non-blocking collectIfDone is a working
> option but this is not scalable because I have to periodically poll each
> SendHandle to get it's status. Indeed, I would like to be able to send
> multiple operations and be notified as as soon as the results arrive.
> After looking in the code, I saw that the blocking is in fact done directly
> in the DataSource. I'm not sure how to implement this. Any suggestions?

It's not trivial :-) The good part is that the easiest way to get it
working is with send + collect as opposed to with call(). If you're
staring at a data source, you're looking at the wrong place for
starters. The core collect mechanism does not use data sources.

The blocking of collect() is done in the ExecutionEngine itself in the
waitForMessages() function. The waiting on the condition variable is
where the timeout needs to be passed on to the OS. From there on, it's
back-tracking up to the user code for adding the time-out argument to
collect(). If you want to provide a call-back to a callbackIfDone()
function, it gets (much) more complex. One way would be to install an
ExecutableInterface object in the target ExecutionEngine which checks
if the operation has been called, somehow collects the results and
calls the callback stored in the OperationCaller. Possibly the
GlobalEngine or the caller's engine could be used to execute the
callback such that the target EE does not get burdened with executing
client callback code. There is already a minor callback mechanism in
place between EE's, since waitForMessages() implements this waiting
for a DisposableInterface object.

Once you get this running for the core c++ operation objects
(LocalOperationCaller), it won't be hard to extend it to the
OperationInterfacePart interfaces and the CORBA interfaces, I hope.

Not something you'll finish in a day....

Peter