Re: message broadcast (was abandoned pengines)

On 02/08/2014 03:56 PM, Anne Ogborn wrote:
> 
> 
>> 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)?

Possibly library(broadcast) provides a suitable user interface.
My remark was more about something to make that work at the machine
level.  At this moment, there is simply no good way to implement
cross-thread broadcasting.

> 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).

Yes, broadcasting can work pretty nice.  That is why Anjo Anjewierden
and I created this very long ago.  That was before the days of threads
though.  Library TIPC also works on top of library(broadcast), but
between Prolog instances (possibly on multiple machines).

> 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

Spaces are basically created by Prolog unification.  You just broadcast
space1(Term) or space2(Term), or whatever schema you can think of that
supports the modularity of your application (e.g., nested spaces, etc).

> 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.

You could implement clock-like behaviour using pthread barriers I guess.
I'm tempted to postpone such things until we need them.

> 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.

At the moment you can hack it by keeping track of the `bag of users'
that is alive.  That, as we concluded, is not ideal :-(

	Cheers --- Jan