vanrein / perpetuum Goto Github PK

We should split the compiler, so packages can be more subtle about dependencies

• the compiler loads and directs modules
• the compiler has basic knowledge of Petri Nets and PNML files
• modules with implementation models: tabular, bitfieldvec
• modules generating for languages/libraries: C, Erlang/OTP, C/MPZ, ...
• not all implementations models will work on all languages/libraries

We will need to have a full grasp of what needs to be generated before we can split the functionality; specifically, issues #6, #9, #10, #11 and #13 need to be resolved first. Until then, we will be stuck with a monolithic compiler that needs all of pntools, cmph and that may even generate all output in one go.

Perpetuum is useful for (and intended for) key management process control. It may even live through the life of a process and wakeup near its end for short-lived secrets. To make this work, it can help to hibernate processes during the days that they are inactive, ideally after minimising memory footprint.

The same place may point to a transition with both an inhibitor arc and an outgoing arc. This can be meaningful when the outgoing arc has a lower multiplicity than the inhibitor.

Semantics for 1.1 will be made to blocks this until well-defined, and prior versions always block inhibitors with multiplicity.

The approach may require (in the general case) a split of a place into two identical copies, except:

• one handles outgoing arcs, the other handles inhibitors
• this leads to separate checks for the two constraints: having enough, but not too much
• the split is not needed if the same (p,t) pair does not combine these two constrints
• the split might be avoided for other corner cases that coincide with bit masks... but that is perhaps odd
• to keep the inhibitor-processing place clone up to date, use a negative addend (the other place ensures the outcome is positive)
• note how added and subber now both use signed bit fields

This saves Petri Net state, and recovers it later. Synchronisation may be costly, can we keep it simple?

Complication: Timeout processing needs to be noted, but luckily it can be simply retried immediately after recovery. Limiting it to at most one timer seems fine. Since timeouts are also supported for the synchronous event message, this is a true concern.

• Limit the catch-all in GenMod:transmap/1 so that one placebit more wouldn't fit

  • Make a new testrun:

    1. Incrementally apply reflow_transmap()
    2. Invoke GenMap:transmap() with incremental numbers
    3. Compare these transmaps
    4. This crashes when bit counts are off
    5. Make 10 iterations, more than the compiler generates
    6. Perhaps: Make a syncrun() against each outcome

This is an auto-trigger capability, and may be centered around numbered hints that end up in flags carried around the loop; the loop can (if hints exist, and Colour changed since the last attempt) fold over the transmap to process those that are hinted, and to collect new hints. (One bit can hint that something was done at all.)

Application-driven hints can be returned as {retry,Hint(s)} and processed upon later process_hints() invocation, or automatically retried for asynchronous signals (without EventData).

The big thing about hints is how they shall be configured; it requires application logic; this is not available to the compiler, but it is during indstantiation.

Note that hints in no way undermine Petri Net semantics, where transitions may fire at random. The hint behaviour can be manually crafted by sending signals from transition callbacks to the application logic.

Specifically, we are looking into libev which appears to be the best one at present, in terms of scalability, portability and knowledge captured.

There are a few possible relations to consider, and ideally we would not pin down the Perpetuum users, but leave them free to make the combination they desire:

• Perpetuum produces scheduler code; this can be invoked to process an event, but it might run indefinitely, or simply a long time. There is no reason why the scheduler could not grant a bit of control over its looping and repetitive behaviour so an event loop can make its callbacks without handing over full control.
• Perpetuum might respond to callbacks that arrive as networking events and, through translation in a plugin library, end up being delivered to Perpetuum as a transition firing attempt (by way of an event that happens to pop up).
• Perpetuum triggers actions in response to transitions being fired, or more accurately, it tickles actions in an attempt to fire transitions. Actions may simply be calls made to routines (probably that's the clever one, it certainly is the most direct one) or they may be callbacks made through an event library. Note how the former can be used to implement the latter.

This is considered a Good Thing(tm) by Erlang engineers.

We have considered a few models up to here:

Request/Response. This is where Rick's idea for Perpetuum came from, as a model of asynchronous processing, cutting long-lasting (remote) requests into a request/response pair and treating each of these atomically on a transition. Requests would be outgoing actions, responses would be incoming events (and probably extend the logic of a surrounding event loop).

Longer Activities in Places. This addition by Adriaan meant that we did not have to explicitly write down requests and responses. We could make the following transitions dependent on the exit code or another form of return value, perhaps the errno variable, to accommodate more flow control.

Multiple outputs. One longer-lasting process could bring out more than one output. A good application would be an LDAP query that responds with any number of SearchResult messages before it sends SearchDone. It is attractive to be able to process the individual SearchResult messages separately, so their contents can more easily be dissiminated over the rest of the graph. This was not possible with a transition looping back to the place holding the long-lasting activity, but we needed that to retain the Petri net semantics that supports analysis. So we had to explicitly start the long-lasting activity before the place.

To suppress or trivialise reflow, and to change the reach of pre-expanded integers. Use with erlc -D...

Have a cache to share structure?

As described here:

An inhibitor arc drawn from place to a transition means that the transition cannot fire if the corresponding inhibitor place contains at least as many tokens as the cardinality of the corresponding inhibitor arc.

This is supported by GreatSPN, so the tools we recommend already do it. We just need to be a little more clever...

Move code that computes marking and canfire from Petri Net processes to caller. Specifically, rewriting internals into external handles such as atom()s naming transitions and places.

Since there may be (far) less callers, this should be more efficient in terms of storage size per Petri Net. Thus, is would help to have very large numbers of Petri Nets around.

It would not help to speed up parallel computations based on introspection. Usually however, introspection is not done but it is left to the Petri Net to backfire when a transition cannot occur (and the marking is not of external interest).

A few mechanisms can be thought of for composing Petri Nets:

• Combining same-named transitions. Transitions fire unpredictably, and additional arcs add nothing but constraints to that.
• Combining same-named places? This would seem to tap and inject tokens from places when viewing a partial Petri Net. May be a break with the concept, if not carefully done.
• Refinement of the atomic (not zero-time) transition into smaller transitions. May be a break with the concept, if not carefully done.

These can be really helpful in managing complexity. When the models are supplied as a list, the compiler can, wel, er... compile them into a larger one. Since the editor and simulator are likely to not follow this, the emphasis on predictable semantics has been added above.

At the present time, it may be that the only thing we shall consider are the same-named transitions.

Error for kxover_server:transmap (58) is unexplained, apparently a problem with the "when" condition.