Make 'slots' concurrent #9

New Issue

spivee · 2025-06-24T09:09:46+09:00

spivee commented

2025-06-24 09:09:46 +09:00

We have 'solvers' running in the OS, 'workers' parsing their results via a separate erlang port each, and then the client's 'server' receiving exit statuses and starting new 'workers' as needed. The language is confusing, but this is otherwise a good use of erlang's lightweight concurrency.

We should go further with this, though, and add another layer of process indirection, to offload as much of the 'server' complexity to the erlang runtime as we can. We want each 'slot' to be a process, so that the 'slot' logic can simplify down to

ask the server for a nonce
spawn a worker process for that nonce
report the result
repeat

This 'slot' should not crash, so if it does crash, we are in the realm of fault tolerance, and can configure a supervisor to restart the worker, or propagate the crash upwards, as necessary.

Then the server no longer deals with restarting slots, nor with restarting workers, so it is simply a nonce allocator, and interface for the workers to report back to... In other words, the server should be split into a service=>worker pattern, probably using zx template swp.

We have 'solvers' running in the OS, 'workers' parsing their results via a separate erlang port each, and then the client's 'server' receiving exit statuses and starting new 'workers' as needed. The language is confusing, but this is otherwise a good use of erlang's lightweight concurrency. We should go further with this, though, and add another layer of process indirection, to offload as much of the 'server' complexity to the erlang runtime as we can. We want each 'slot' to be a process, so that the 'slot' logic can simplify down to 1. ask the server for a nonce 2. spawn a worker process for that nonce 3. report the result 4. repeat This 'slot' should not crash, so if it does crash, we are in the realm of fault tolerance, and can configure a supervisor to restart the worker, or propagate the crash upwards, as necessary. Then the server no longer deals with restarting slots, nor with restarting workers, so it is simply a nonce allocator, and interface for the workers to report back to... In other words, the server should be split into a service=>worker pattern, probably using `zx template swp`.

spivee self-assigned this 2025-06-24 09:09:46 +09:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: QPQ-AG/gmhive_client#9