Re: Tasks - communication
- Posted by useless_ Oct 21, 2012
- 1678 views
I like the D Programming Language's approach to this, namely that all data is assumed to be shared between tasks unless explicitly said otherwise.
Seconded.
Global broadcasts between tasks ate more cpu clocks than narrowcasting. It increased the msg queue for each task, and the overhead in tracking which msgs got delivered and could be deleted to free memory. Memory use sounds trivial until you consider the size of msgs that could have been sent from http.e, for instance.
Agreed. The shared data should be global, rather than duplicated via messaging. It's faster for two threads to use the same block of memory than to have two processes communicate via IPC to notify each other of updates everytime one of the processes touches the object.
While IPC is all fine and all, it makes life difficult for the task msg system to know if all the tasks read it, and to keep them in FIFO order. Ditto sorting them. My global system didn't duplicate the global msg, it merely kept it and updated the to_who based on who did read it. When all the to_who of a msg (one task, or 2 of 5 tasks, or all tasks) got deleted, the msg got deleted. It used no more memory than calling a procedure with the data or assigning it a variable.
Perhaps I'm simply not thinking far enough ahead though - one day we may very well attempt to run multiple threads across different computers (and perhaps different architectures) on a cloud, for example.
I doubt it. I run a cluster, altho it's a lot less useful after the winxp SP that throttled down lan speeds. Decades ago i tried to discuss a Euphoria based RPC for irc bots and Ai, and i think the opinion from everyone was that was illegal. Or it's possibilities were illegal. Or it had the same pitfalls a Microsoft's RPC interface. Or "you're just trying to break into my computer!". The suggestion went nowhere in a hurry. I did link code (written in php on a nix box) on a webserver to Tiggr (written in Euphoria on winxp) for a browser and general http (uploading and downloading and interacting) interface to her, that worked nicely, handshaking and data passing back and forth real neatly and quickly, but also went nowhere.
So i provided for broad- and narrow- casting. You choose your best option for the app you are currently coding. Sue me.
I suspect that I'd normally choose narrowcasting most of the time, if I had to choose between those two options.
If you had to choose? Is this a undue excessive burden? You are not required to choose, you could flip a coin or ignore one option. I didn't want the burden of choosing for you, so i wrote in both options, i thought they'd be useful. Sorry.
useless
