Re: abandoned pengines

On 02/07/2014 11:47 PM, Anne Ogborn wrote:
> My application is a map based game. Basically I'll be moving around
> markers on the map.
>
> My plan is to have the main page start a timer loop for each type of
> marker. When the timer fires it'll create a  pengine , iterate
> through the data until it fails, and destroy the engine.
>
> Is this a reasonable method?

I think that is fine.  Pengine creating time is low (less than a
millisecond, so way less than network delays in you are not
inside a LAN).

> What happens with pengines that are abandoned?

There are two mechanisms here.  The pengine times out (by default
after a minute, controlled by a setting) and if you use HTTP sessions,
you can set a max for the number of pengines related to the session.
The default is in fact 1.  Creating a new one kills the (hopefully
stale) one.  Still unsure whether silently killing is a good plan.
It often does what you want, but raising a resource exception seems
more consistent.  Possibly this should be an option.

> Could I instead have the calls within the pengine (Presumably some
> public API on the server) block waiting for more data? This would
> allow me to push data. If so, I have a relatively complex job of
> thread handling that seems contrary to the spirit. Am I missing
> something that would allow me to do this more simply? To make the
> discussion concrete, take as an example player position. In our game
> every player sees the other players as markers on their map.

You should be able to do this by having a continous pengine associated
to each player and use pengine_output/1 to send updates.  That boils
down to a long polling architecture.  I'm afraid this is not an easy
choice.  I do think it isn't very hard to implement though.

> Each player's javascript will report their position whenever they
> move more than some constant number of meters. This information needs
> broadcast to all the other playrs
>
> So, my naive implementation is
>
> create a pengine that calls a public API on server, (marked safe,
> obviously), that waits for input, handles, and repeats in an infinite
> TCO recursion.
>
> create a second pengine that gives an infinite series of solutions,
> each of which is a new player position, blocking until it has a new
> position.

I guess that can also work.  I think that Torbjörn Lager would consider
using pengine_output/1 more elegant?

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

Some systems have that, allowing threads to block on a database change
in general or wait for solutions, such that adding a clause releases one
or more other threads backtracking on that predicate. I think Ciao has
this. There is some elegance in this as it basically replaces message
queues. There is also something strange as it violates the logical
update view.

The downside of POSIX CVs are that they easily deadlock, but their
semantics is much cleaner than MS events. The Ciao approach has the
already mentioned disadvantage and creates something that is (I fear)
confusingly similar to message queues. Just the QuProlog
wait-for-db-change than? Problem is that this may cause many unneeded
wakeups.

Suggestions are welcome.

	Cheers --- Jan