[Pipet Devel] Open DX as a loci skeleton?

[Harry Mangalam]

Not to make everyone heartily sick of this thread, but it looks like the DX
arch CAN be made CORBA-aware with relatively little (hah!) effort.  If so,
that would make it a 
viable candidate for MY immediate use, and it sounds like this might be of
wider interest as well.

I need to look at the code mentioned with one of our CORBA programmers to
see how easy it is to in fact do this.

Best
Harry

=====================================
gabra at us.ibm.com wrote:

Right.   I'd be interested in hearing about what you come up with.  If you
need a hand, let me know.

Greg

>Harry Mangalam <mangalam at home.com>@opendx.watson.ibm.com on 02/14/2000
> To:   opendx-users at opendx.watson.ibm.com
> cc:
> Subject:  Re: [opendx-users] Dx and CORBA
> 
> Hi Greg, thanks for the input,
> 
> So if I follow you, you (or rather *I*) could write a  module that takes
> care of communications with CORBA which would just be another input module
> for DX.  Depending on the CORBA services required, any and all data could
> flow in thru this channel and be processed in DX as would any other.  This
> module would be responsible for setting the granularity of the data to be
> processed, as it would release execution when a complete data chunk had
> arrived.  Real time execution would essentially be no different, except
> that the granularity would typically be quite small.
> 
> For output, it would be the same - (simplified), all DX modules that want
> to send data to CORBA services would just be wired to a 'CORBA output'
> module which would then take care of the interchange.
> 
> Or no?
> 
> Thanks for your input!
> Cheers
> harry
> 
> gabra at us.ibm.com wrote:
> >
> > While there is no built-in CORBA interface for DX, there are hooks in DX
> to
> > support asynchronous input.  The trick in DX is that modules generally
> are
> > scheduled for execution when their input has changed.  Typically, this
> > input consists of data arrving on the
> > inputs of the modules - the wires connecting a module to its precursors.
> > In the case of asynchronous input, what you do is to create a module that
> > has two functions.  One, a "watcher" procedure,  keeps an eye on an input
> > stream, and kicks DX to let it know that input has arrived.  The other is
> > the module itself, which actually reads the input  when it runs, creates
> a
> > DX data object from the input, and  passes it on down the network.
> >
> > In the samples, you'll find a prototype in outboard/watchsocket.c.   This
> > sample module (as you might guess) watches for data input arriving on a
> > socket.   It opens the socket, and then registers the fd along with the
> > "worker" procedure, to the list of fds that DX watches.  When input
> arrives
> > on that fd, DX calls the worker procedure, which in turn calls
> > DXReadyToRun, passing in the module's identifier.  This indicates that
> > input has changed on that module, and next time DX executes (immediately,
> > if DX is in ExecuteOnChange mode) the module will execute.  The module
> then
> > reads the input off the socket, creates an object, and passes it out.
> >
> > This scenario can be generalized easily.  Your module spawns a thread
> that
> > blocks waiting for input in whatever manner is appropriate for the
> > communications medium you are using.  When input arrives, your thread
> > releases and calls DXReadyToRun, just as in the sample.
> >
> > I hope this makes sense.
> >
> > Greg
> >
> > GENE <genepaul at flash.net>@opendx.watson.ibm.com on 02/12/2000 02:18:04 PM
> --
> Cheers,
> Harry
> 
> Harry J Mangalam -- (949) 856 2847 -- mangalam at home.com

-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 -- mangalam at home.com