[Home]InterLanguageCommunication

FlowBasedProgramming | RecentChanges | Preferences

Inter-Language Communication

PaulMorrison:

DenisGarneau has suggested that we allow multiple FBP environments to coexist in an application - one for each language we support, e.g. C++, C# and Java, and let them communicate by standard operating system facilities that they are able to share, e.g. files (very slow!), ports, MQSeries, pipes, sockets, etc. Within a few days, I had successfully made some JavaFBP components communicate by means of sockets (the network is shown below); and a few days later a JavaFBP network communicated with a C#FBP network, using the same generalized components on the JavaFBP side.

A C++ .exe file can be run as a C#FBP thread, so this could be run concurrently with other C# threads within a C#FBP network - either a single legacy C++ program, or a THREADS network. In either case, a sockets component or subroutine could be added to facilitate communication with C#FBP or JavaFBP. My concern about green threads (as in THREADS) hogging the CPU wouldn't apply in this case, as JavaFBP or C#FBP threads would preempt as needed.

The previously mentioned idea of using POSIX to build a preemptive C++ FBP dialect only seems necessary if you have several CPU-intensive C++ modules that need to multithread with each other, and (probably) were not written using the FBP technology.

So what this says to me is that we are very close to having a super-network that can have Java, C# and C++ all communicating via streams of data within one application!

MatthewCrewe:

The trick is to break the concept that an application is a single execution environment, running a single language. Instead the application is a simple scheduler for 1..n environments which communicate via any of the means you mention.

This is (as far as I can tell) very similar to DBUS: http://www.freedesktop.org/wiki/Software/dbus

The main issue for me is resource usage and keeping copying to a minimum. If you pass around very little data then you won't find this a problem, we can work with GB's!

You can use shared memory (on windows, not sure about Linux). But different languages access data differently, you then get performance hits copying/re-formatting data to suit. One of the benefits I see of FBP is allowing a mixture of languages to work with data, performance might be an issue for FBP and some applications?

Maybe, the solution is to put functions which have high performance requirements "next" to the data i.e. in the same environment and the same language. You could use handles to represent state, in a similar way to operating systems. External users would only work with handles to the data, cookies for data. I guess the manipulation functions would also have to live with it - This is getting a little like object orientated programming! Except I want data and *some* associated functions to flow! Hmm, this is passing pointers to standard OO objects - Not very FBP?

Alternatively I would like the ability to query data for suitable API's or connection points.

E.g. C++ code could say:

 foo(in big_object) {
    ...
    int* data = big_object.GetPointer?<int>();
    ...
 }

A C# client could say:

 foo(in big_object) {
   ...
   int[] data = big_object.GetArray?<int>();
   ...
 }

So, maybe what I need is the ability for **data** (or its handle) to provide API's/accessors for each execution environment. When the data resides in the same language/environment the access penalties are low otherwise a possible copy occurs. Which still feels bad because you end up re-implementing components or adding new ones which work in the same environment as the data (using the same language).

The only solution I can see (at the moment) is to write small domain-specific languages for such data, these compile to the native environment and have a slim API to the data. To modify it you pass in the code e.g. from above:

 foo(in big_object) {

   string command = "
       int[] data = get_data(); // Quick - no copy
       int[] histogram = ...
       // compute...
       return histogram; // Arg - Copy needed
   ";

   int[] histogram = big_object.Execute(command);
 }

This is similar to shader programming (a small light goes on in my head), given graphics processing has high performance requirements and quite large data this is possibly why this field has gone this way. Also a GPU is similar to a FB component in many ways. I note return values would need copying, so possibly handles would help again. Although this is similar to the OO approach the fact that the operation is defined externally feels closer to being FBP?

PaulMorrison:

I have built a couple of JavaFBP socket components, and successfully run several test cases. Here is the network:

protected void define() {

    component("Gen", Generate.class);
    component("WS", WriteToSocket?.class);
    component("RS", ReadFromSocket?.class);
    component("WS2", WriteToSocket?.class);
    component("RS2", ReadFromSocket?.class);
    component("Disp", WriteToConsole?.class);
    component("Passthru", Passthru.class);

    connect("Gen.OUT", "WS.IN");
    // connect WS to RS via socket!
    connect("RS.OUT", "Passthru.IN");

    initialize("100", component("Gen"), port("COUNT"));
    initialize("localhost, 4444", "WS.PORT");
    initialize("4444", "RS.PORT");

    connect("Passthru.OUT", "WS2.IN");
    //connect WS2 to RS2 via socket!
    connect("RS2.OUT", "Disp.IN");

    initialize("localhost, 4445", "WS2.PORT");
    initialize("4445", "RS2.PORT");

  }


The folks at Stack Overflow have suggested a number of communication possibilities - see http://stackoverflow.com/questions/773097/inter-process-communication-between-languages-operating-systems.


MatthewCrewe:

I also went dual boot recently (fed up with windows), installed Ubuntu (really nice distro.). Before dual boot I used (and still do) Sun's VirtualBox? VM to run Linux in - It's free and works brilliantly. [put here for reference purposes]

Bumped into this: http://blog.objectmentor.com/articles/2009/04/20/is-the-supremacy-of-object-oriented-programming-over and thought it echoes my feelings and I'm sure it will reaffirm your views and delight you that the shift is starting.

BTW, Microsoft are starting to see the light too: http://blogs.msdn.com/maestroteam/


FlowBasedProgramming | RecentChanges | Preferences
This page is read-only - contact owner for a password | View other revisions
Last edited May 5, 2009 1:29 pm by PaulMorrison (diff)
Search: