Symbolic: Synch Operation Pool

Most of the processes, script or operation, you can run using Symbolic are asynchronous, this means that multiprocess/thread control is delegated to func. There are some other situation where you may need run process in synchronous mode: some admin procedures should be run directly waiting for the response (i.e is needed to going on or to complete symbolic configuration).

Following the standard "running channel" used to run async script, can generate a bottleneck: my RunnerJob must wait the end of ran process and so it's impossible to run any other operation till the end of the async one.



To solve this problem Symbolic has a Pool Manager used and called from RunnerJob. Is a bit more than simple synchronized list of processes: you can decide how many "concurrent" synchronous processes you want and it exposes some method to "book" your process execution, send process and check process status.



Following diagram exposes how Symbolic manages synch operations.







  1. User or administrator "try" to run a synch operation
  2. User calls reach the RunnerJob that, calling PoolManager try to book a place for sync job execution
  3. If there is a place to process user request, PoolManager responds with the position assigned in pool list. If you want this is what happens when you want to book an hotel room or a theater seat: you call, if there's what you ask you received booking number, in any other case you have to wait.

  4. If JobRunner receives a useful position in the pool list, he start the process asked from the user and then send reference to running process and provided position to PoolManager. If JobRunner receives a "no free places found" it returns an answer the user with an error message.
  5. Process is queued in the pool list and it goes ahead with the execution
  6. Any "X" seconds there is another job, ControllerJob, that calls PoolManager asking if there is any process that has finished the execution
  7. If something is found a messege ControllerJob sends a message to User with the execution result.
This kind of implementation is something like asynchronous call for the Symbolic engine because there is no "internal" process that wait for the execution end. It's only an synch call for the user that can do nothing more on the application till the end of the process he ran.