Ticket #124 (accepted feature)

Opened 7 months ago

Last modified 7 months ago

Skiller Multi-Channel Execution

Reported by: tim Owned by: tim
Priority: critical Milestone:
Component: Fawkes Version:
Keywords: skiller Cc:
Git Branch:

Description

Currently the skiller accepts one skill string and executes it in the Lua sandbox. Multiple skills are executed concurrently by putting them on the same level in the skill string, i.e. concatenate them semi-colon separated. But with this method only the aggregated skill state can be queried, i.e. if one skill fails, the whole execution is considered to have failed and only if all skills have succeeded, the skill status is final.

To remedy this shortcoming we will implement multiple skill channels. A skill channel is a separate line of execution. Whenever a skill string is ordered for execution, it is assigned to one of the free channels. An own sandbox is generated in which the skill string is executed. The message ID of the ExecMessage will be stored to denote in which channel the skill string is executed. For the beginning we will start with 8 skill channels. We may later extend this if we see the need.

The SkillerInterface will be extended to have an array msgid/channelid with a length of 8. In this array for each of the channels the message ID of the skill string currently executed in that channel will be noted. This allows the agent/skill tool to determine which channel to monitor.
Likewise the status will become an array of 8 stati, one for each channel.
There will be a message to stop the execution of a particular channel, and one to stop all. The source-level compatibility will be maintained, at least mostly meaning that minor changes might be necessary, but that the existing semantics continue to work if usage is limited to a single channel.

The decision has been made (by Patrick and me) for now to use one Lua context in which all sandboxes are created and generated, effectively causing the same interlaced execution of multiple skills that we have today. This keeps things simple and is sufficient for our current scenarios. Later this might be extended to true parallelism by having a number of Lua contexts in separate threads executee in parallel (possibly using luaproc channels for communication if required).

Change History

Changed 7 months ago by tim

  • status changed from new to accepted
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Subscriber, Participant

  • Fawkes Trac List(Always)
  • Tim Niemueller(Reporter, Owner, Participant)