Re: Message-passing framework and 'actor' objects
- Posted by jimcbrown (admin) Feb 07, 2020
- 1523 views
Some time ago i wrote a preprocessor to make a universal type, wider than global type: it shared variables between OE programs.
It also eliminated the bottleneck of blocking calls, such as http.e (http.e still blocked, but if your http.e hung, it need not stop your main block of code or any other program).
Hey, me too! It was a preprocessor based on my threads.eu library.
OE has a user type check. When you assign a value to a variable, that typecheck you write is called. My preprocessor replaced the "universal" type with "global" and added a call to a included file which used window's msg passing to broadcast the variable name and contents, which the include file of the other programs would pick up and handle.
I didn't bother with the user type check (instead manually inserting code to validate each time) and I used sockets instead of windoze msg passing, but otheriwse it sounds like we more or less had the same idea.
It also shared procedures/functions between programs.
A side effect is it was possible to shut down an app of shared procedures, re-write it, and re-run it, without shutting down those programs that made calls to it.
Mine didn't do that (since the goal was to emulate threads, all instances have the same copy of code). However, adding those features would actually be pretty straightforward - this is standard with microservice arches.
I did not try this compiled, only interpreted.
I can't think of a reason that your preprocessor+library wouldn't work compiled, though...
This isn't such a big deal. The OE group has allowed interpreted only featurs before, e.g. task_yield() not working in a compiled shared library.
This was not a welcome addition to OE.
All this is, of course, blasphemous to the tenets of Euphoria.
Well, it otherwise would have been a perfect, welcome addition to OE. I don't remember the library now but from what you've described, it does suffer from one problem:
which used window's msg passing
So it is OS specific. Stuff that goes into the OE stdlib has to be cross-platform. The only exception is if it's a low-level wrapper for a low-level OS interface.
My threads.eu also only worked on *nix due to the fact that it relied on fork(), that meant that it also could not have gone into OE proper.
I could not even get my pipeio.e library into OE alone, since it was *nix specific. Someone else had to combine it with an unrelated w32 pipe library before it was accepted into the OE stdlib as std/pipeio.e .. and it's changed quite a bit since.
A lot of excellent but platform-specific Eu libraries like win32lib don't make the cut either.
The other thing is that even stuff that makes into into the OE stdlib can later be replaced by something else. For example, look at the current Roadmap - which has std/http.e phased out by Euphoria 5.0 and completely replaced with libcurl.
Likewise, Greg is replacing the current website code (made by Jeremy and friends and up to the latest standards when it was started .. more than ten years ago) with Euphoria MVC.
Thus I could easily see your library being replaced in the stdlib with a different one that used ZeroMQ .. which has the added benefit of allowing the programs to run on different boxen, in a more distributed fashion.
