Re: Tasks - communication
- Posted by jimcbrown (admin) Oct 21, 2012
- 1673 views
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.
Agreed. Hence why I said I didn't want to go this way.
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.
Sounds like a sound implementation of task messaging to me. One made possible because it's possible to share variables (and implicitly the address space) between tasks.
Going on a tangent:
I misread Derek's original post, however. I think that sharing variables between threads BY DEFAULT is a bad idea. It should be possible to mark a variable as shared between threads, but I feel that having this the default is a bad idea. I feel that this is the source of bugs in many notive multithreaded progrrams.
This is less important for cooperative nonconcurrent tasks, but I don't have a problem with the above principle being applied to tasks as well.
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.
Understood. I'll note your agreement with me then.
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.
All before my time, I guess.
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.
Although having both choices is useful, having only these two choices to the exclusion of all other possibilities is an undue excessive burden. Having to ignore an option would be an even greater undue excessive burden.
