-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[WIP] [POC] Awesome runner #178
base: master
Are you sure you want to change the base?
Conversation
66d040b
to
f6c4259
Compare
updates:
|
update:
|
require "concurrent/array" | ||
|
||
module Floe | ||
class AwesomeProcess < Thread |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would have preferred not using a thread per process and not using an AwesomeSpan
centric model.
436600d
to
af7918d
Compare
f518699
to
61d4123
Compare
update:
update:
|
Checked commits kbrock/floe@e25d67e~...514bed0 with ruby 2.7.8, rubocop 1.56.3, haml-lint 0.51.0, and yamllint |
This pull request has been automatically marked as stale because it has not been updated for at least 3 months. If these changes are still valid, please remove the |
This pull request is not mergeable. Please rebase and repush. |
This pull request has been automatically marked as stale because it has not been updated for at least 3 months. If these changes are still valid, please remove the |
depends upon:
Overview
So that begs to ask the question on how to implement a runner that manages its own subprocesses.
Implementation
I came up with a synchronous and an asynchronous implementation. They get converted across with a commit.
I feel the synchronous implementation may be the best one, otherwise it has a bunch of threads hanging around.
commits:
Issues
This doesn't work perfectly since
AwesomeSpawn
escapes$VAR
and that makes this pretty useless.But the goal was more focused on the Threads and stuff rather than the actual awesome spawn part.