Don’t worry if some of the stuff in here does your head in – it’s doing my head in as well. At present Plain is no more than a collection of ideas with a lot of loose ends that we hopefully will manage to bring together.
We do a lot of multi-threading in Plain – we do so through distributed processing, parallelism and events. This is one of reasons I want the syntax and the assembler to deal with this – as a Plain developer I want to focus on what we do without having to worry about the details or if I get things like multi-threading wrong. My objective is that we should use C/C++ for the complex modules and hardware integration while we use Plain for system wide Logic. And I want programming to be simple so we can get more done with less resources.
We do however have one loose end – Events. The events returning from a call is not multi-threading, but event callback’s from C code will be. This is technically the same challenge we face in Parallelism – if we control 20 operations it also means we are waiting on 20 events while we continue with something else or just sit idle waiting.
Moving on a bit I also have an issue with the On statement. In it’s current form it is attached to Call – But, what if I want to do a lot of operations and just collect events & process them later? We often talk about Parallelism as the same operations in parallel, but with remote function calls we could actually start a call, start the next etc and decide that now is the time to wait for everything we have started to finish. To do so I need a mechanism that is not bound to the Call instruction.
Letting On be an instruction and introducing an Event queue will almost fix this – I am not to happy with the event queue, but as we send parallel operations out we actually need a mechanism in the VM to collect events and queue them.
As for Syntax we have used On & Event – I intended for Event to be the declaration and On to be the catching – but for C code we have used Event for the implicit catching as well. I need to tidy up my syntax and be more consistent.
I also have the Mandatory event catching that becomes a challenge if we detach On from Call – but I am sure we can solve this somehow.
use System Module MyModule Event CModule SomeEvent() println ("I got an event from C") End End
This is how I planned to bind Plain code to C code. The idea was that RTL should look for a declaration of CModule.SomeEvent with no parameters and forward any call to this into Plain code. This will work, but it seems inconsistent with the use of a separate On statement.
use System Module MyModule Event CModule.SomeEvent() println ("I got an event from C") End Call MyRemoteFunc() println ("Called MyRemoteFunc") On MyRemoteFunc.Error() println("Hello from MyRemoteFunc") End End
The “Event” declare a piece of code that can be called from C anytime – the On test if it exist an event and if it does we process it – top down. The challenge here is however that we might test for MyRemoteFunc events to early – if the event is raised after we execute On we will not catch it – so we need to introduce a state mechanism that wait for events.
use System Module MyModule Event CModule.SomeEvent() println ("I got an event from C") End Call MyRemoteFunc() println ("Called MyRemoteFunc") State ... On MyRemoteFunc.Error() println("Hello from MyRemoteFunc") End End
We did earlier have a Call..On that I now replace with a State..On. This will simply wait until one of the events in it’s list happens. I can still keep my Call..On syntax as an implicit State. One of my key objectives with Plain is “State-engine and event based logic” and introduction of a State instruction & event queue starts to sound like a big move in the correct direction.
to be continued in part 2