Open renatomassaro opened 7 years ago
recursive
process type was implemented at #410, refer to LogRecoverProcess
for usage example.
Implementation of recursive
process is based on the SIGRETARGET
signal. When the process objective is reached, the process may perform its side-effect (e.g. pop out a log revision; mark a file/connection as found; etc) and then send the retarget signal.
When SIGRETARGET
signal is received, Processable.retarget/2
is called. It's up to each process to define how the next iteration should go, but basically during the retarget
step, the process may change any object target(s) and its objectives, effectively creating a new iteration.
Note that, to avoid race conditions, one should issue the SIGRETARGET
signal only after the side-effect has been committed (performed).
Wo4king on the game but when do we get refunds and replays on the hacker experience 2 discord ur over due on ur 3-5 business days
On Thu, Aug 16, 2018, 06:09 Renato Massaro notifications@github.com wrote:
recursive process type was implemented at #410 https://github.com/HackerExperience/Helix/pull/410, refer to LogRecoverProcess for usage example.
Implementation of recursive process is based on the SIGRETARGET signal. When the process objective is reached, the process may perform its side-effect (e.g. pop out a log revision; mark a file/connection as found; etc) and then send the retarget signal.
When SIGRETARGET signal is received, Processable.retarget/2 is called. It's up to each process to define how the next iteration should go, but basically during the retarget step, the process may change any object target(s) and its objectives, effectively creating a new iteration.
Note that, to avoid race conditions, one should issue the SIGRETARGET signal only after the side-effect has been committed (performed).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HackerExperience/Helix/issues/324#issuecomment-413509096, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKQCT8eu7NuSmrWzaEpwMutAZeGLKyPks5uRVMFgaJpZM4QKi3k .
Process lifecycles:
direct
- Process with a clear goal/target/objective, has an ending. The time required for completion is usually shown to the player. Examples: FileTransfer (download/upload), editing a log, overflow/bruteforce attack.recursive
- The process runs endlessly. It has a target, but the user doesn't know which one exactly is it. Once the target is deemed processed, the user is notified about it, and the process selects a new target, starting from scratch. If no targets are select, the process runs anyway, and the user does not know that. Examples: LogRecover (system-wide), FileSeeker.daemon
- The process runs endlessly. It usually does not have a target. Instead, the process is used as means to 1) enabling some in-game action or 2) increasing/hardening in-game defense against remote attacks. Examples: Firewall (passive).Current TOP, rewritten at #322, only supports
direct
. Adding bothrecursive
anddaemon
should require minimal changes to the allocator, and a new interfarce underResourceable
(in order forrecursive
protects to select the next target).Edit: support for
recursive
process added at #410