Re: message broadcast (was abandoned pengines)

> javascript timer reads the GPS location.
>
> If we've moved far enough, does a pengine_input with the data. On the
> server side,***a miracle occurs*** probably involving the cryptic
> comment " * A dynamic clause database, private to the pengine, into
> which other processes may assert clauses. These clauses reside in the
> module pengine_sandbox.
>
> That passes the data to all the 'second pengine's and lets them
> unblock and send a new position.

Your miracle typically involves message queues. What seems to be lacking
in the current thread API is a way to block multiple threads and release
all of them if some event happens without the initiator knowing which
threads are waiting. This would relate to POSIX condition variables or
MS events.


That seems pretty unweildy. 
Whats needed here is an actor architecture. There needs to be a way for 
code to listen to broadcasts from other pengines.  Maybe library(broadcast)?

My old job with UH HHP involved lots of LSL script language. It was an actor language
like this, and had a suprisingly high degree of decoupling because of the broadcasts.
The decoupling made for dramatic code reuse. It was common in Second Life to find
people who 'programmed' only by dropping scripts into objects (activating agents).

However, one of the things that made it useful was the way there were 'spaces', rather
than your global 'ether'. Additionally, it'd be very convenient if the association with pengines happened explicitly, so when a pengine died it would unlisten itself.
LSL supports the idea of 'states' - transitioning between states flushes the message
queue. This makes for clean behavior transitions in that environment, I'm not sure it'll
work here. Even in LSL, there's an exception - timer events aren't flushed.

I need to get this project out - I think I'll go ahead and just poll using a pengine, but definitely  this is a missing and needed part of the system. Most real web applications are either user <--> database   or   user  <--> user <--> user <--> user   bag of users communicating.  Need to support that second use case.