--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Samuel,
Great post.
I was a bit confused by the heading "FBP at all suitable for distributed computing?" because the paragraphs that follow do not discuss FBP or distributed computing. Instead they discuss Erlang VM's poor performance for certain parallelism.I can't find anything that explains why you don't think FBP is well suited for distributed computing. Have you dropped some paragraphs in an edit?I was hoping to see a discussion around the nature of FBP's IPs as persistent entities compared to Erlang's transient messages.
> Let's start with how we do error recovery. > > Imagine two linked processes A and B on separate machines. A is the > master process. > B is a passive processes that will take over if A fails. > > A sends a stream of state update messages S1, S2, S3,... to B. The > state messages contain enough information > for B to do whatever A was doing should A fail. If A fails B will > receive an EXIT signal. > > If B does receive an exit signal it knows A has failed, so it carries > on doing whatever A was doing > using the information it last received in a state update message. > > That's it and all about it - nothing to do with supervisors etc, Ooooohh! THANK YOU, THANK YOU, THANK YOU. *Now* I get it. This is precisely what I was trying to understand. The missing link was sending redundant messages. It all makes sense now -- it's so simple. All I have to do to get fault tolerance at the process level is have a group of N redundant processes waiting for exit-signals and forward state changes to N-1 of them. I could even send to N/2 and have some decent tolerance at the expense of consistency of the nodes.
http://erlang.org/pipermail/erlang-questions/2011-January/055531.html
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
If process A in on machine I and process B is on machine II then when A passes to B there must be a handover of responsibility. This is a powerful concept but it can stand in the way of parallelism.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
It seems to me that your FBP is bringing programming to what I might call a "process control" view of the world. Imagine the control panel in a power station - it shows flows and has coloured lamps etc showing what is working.
It would be very nice to visualise the "state" of an FBP system - green lights on components with low CPU load, red lights on high CPU components etc. little scale indicators on buffers to show how full they are etc.
As for out of band data I think we just need to have a general rule - all data is either {data, X} or {meta, X} all meta data is just passed from inputs to outputs (which ouputs? - all of them????) but can be (doesn't have to be) processed
I also feel the need for some special symbols.
(Now I feel hampered by ascii)
- a circle with out arrow = file source this opens the file, reads it entry at a time until eof and sends the data along the arrow
- circle with arrow in = file sink (the opposite)
So file copy is just a dumbbell with and arrow between the circles :-)
I have several long-term problems "storing things" and "finding things" - now Google has made inroads on finding things. Rob Pike (from plan9, inferno, bell-labs fame) http://labs.google.com/people/r/ has written a paper Interpreting the Data: Parallel Analysis with Sawzall.
Very interesting - this is flow based programming (with a different name) on a grand scale. All these Google machines are just pumping out data in a gigantic flow network.
One idea I had would be to try and create a web from unlinked data. Take, for example, the erlang mailing list - there are tens of thousands of interesting articles in it. If we could automatically link each post to (say) the ten most similar posts then we could turn the email archive into a web site.
This needs the idea of similarity between two texts - implying automatic extraction of keywords (difficult) - also "recommendations algebras" - ie if X likes A and B and Y likes A - then possibly Y might also like B.
Ultimately I'd like self-organising documents that allow feedback.
Another fun thing to do would be to implement a system for FlowBasedProgramming in ErlangLanguage with a nice graphics front-end - I think this is rather easy.
One "device" that would make life *very* easy is the "named persistent pipe" ie a persistent FIFO with named end-points that survives crashes.
That and a graphic front-end to draw the connections would be fun.
Actually a crude "no bells and whistles" variant of this would be very easy.
Then we need a set of filters - to get "legacy code" talk to the FIFO's.
(Incidentally the persistent FIFO model solves the problem of updating code on-the-fly, Just turn off the FIFO. When I give talks I think the "pluming" analogy is great - to change my boiler, the plumber turns of the water drains any extra water out of the system, changes the boiler, re-connects the pipes and turn on the water. The pipe contains the water - if you're careful nothing drips out. *This* is exactly how we should upgrade Software.
BTW I have a suggestion for a language-neutral data format for describing the water :-)
BTW - have you tried Erlang? - (www.erlang.org) http://www.erlang.org/download/getting_started-5.4.pdf is a good introduction.
If you'd like to learn Erlang I would be delighted to help you with any problems you might encounter.
I can set you your first homework "make a fault-tolerant persistent named FIFO - replicated the FIFO on two machines - so that it will still work if one machine fails" - hint use MnesiaDatabase - a simple version is probably less than 100 lines of code - we'll need this :-)
Erlang does not have a native interface to C or C++. All interfaceing is done by pipes or sockets - this is deliberate - interfacing erlang by linking code into the system would be very dangerous if the code were incorrect - so we require that it be isolated in a different process.
Erlang runs on all major platforms. The windows distribution is a binary executable - on unix/linux machines we distribute source but the build process is known to be trouble free on all major platforms.
For about ten years I have been thinking about whats missing in Erlang - how can we make systems that are easier to understand.
I had some ideas here
The central idea is of "reactive components"
These are Black Boxes characterised by three things
IP, Port and protocol
saying
bind Ip,port,protocol
Means there is a thing at (IP, Port) that obeys protocol
Step 1 *specify the protocol* (usually in terms of RPCs)
(Example FTP)
protocol FTP ... ls() => [file()] getFile() => ok() | error()
Step 2 - I refine the types
Type ls() = "ls" getFile() = {"get", str()} ok() = {"ok", str()}
Step 3 - I serialise the type instances
And send them to the (IP, Port)
To fetch a file I send
Content-Type: xml Content-Length: NNN <tuple> <str>get</str> <str>The File</str> </tuple>
and wait for
Content-Type: xml Content-Length: NNN <tuple> <str>ok</str> <str> the file content ....</str> </tuple>
Or
Content-Type: xml Content-Length: NNN <tuple> <str>error</str> <str> ... string ....</str> </tuple>
because that's what the protocol spec says.
What more do I need?
--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.