-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flesh out multi-process reconfigurable network functions #1257
Conversation
Previously, release() would always fail.
This is the first step in refactoring the "app.config" mechanism to be something that's more of a library and less like magical apps.
New file applies scheduling parameters for a data plane.
Also add generic worker.main() export from lib.ptree.worker
* src/lib/ptree/worker.lua: Privatize "Worker".
Store next_time locally in the main() function, and in the selftest, run the main() function for longer than a single tick.
Allow timers to be cancelled.
Having the multiprocess tree and configuration system be implemented as apps was a neat hack that re-used the app abstraction as a way to add a reconfiguration back-channel to a dataplane, but it goes against the abstraction that the core.app / engine facility should really be targeted towards the dataplane domain; it's not necessarily a great generic process composition facility.
This name better matches how users will think of it. Also add functionality to set program name to the manager, and bind the manager to a NUMA node as appropriate. Unclaim the name as the manager stops.
Do assign CPU affinity even if it has to be on a remote node, but warn. Warn if no CPUs available.
Use config-leader-socket to avoid breaking existing clients.
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.
This looks good 👍 I think it makes more sense as a library than set of apps.
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.
Amazing work. I commented on some nits.
|
||
local function fatal (msg) | ||
print(msg) | ||
main.exit(1) |
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.
Perhaps is worth moving this function to core/lib since is currently defined at many places (lwaftr/lwutil.lua, at several modules in program/alarms and ptree.lua).
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.
I will make a note of it!
src/lib/ptree/worker.lua
Outdated
local app_graph = require('core.config') | ||
local engine = require('core.app') | ||
|
||
if opts == nil then opts = {} end |
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.
Also can use the idiom opts = opts or {}
, as you like more.
engine.configure(app_graph.new()) | ||
|
||
-- Now we can exit. | ||
S.exit(0) |
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.
Why not main.exit(0)
?
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.
I do not know. This comes from follower.lua
. I guess you mean os.exit(0)
btw. Can fix I guess :)
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.
Actually, main.exit()
does exist but currently simply calls out to os.exit()
. I think the idea was to be prepared for potential cleanup code in the engine?
self.file:write(self.header..'\n') | ||
self.file:flush() | ||
function CSVStatsTimer:start() | ||
local function tick() return self:tick() end |
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.
What's the goal of wrapping the self:tick()
call instead of calling self:tick()
directly?
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.
It's because timer functions are called without any arguments, and here we need to call tick(self).
OK as this is merged to |
The multi-process facility is no longer a pair of weird apps; instead now it's a library called
lib.ptree
(for "process tree"). There is better developer-facing documentation insrc/lib/ptree/README.md
and more importantly there is example code insrc/program/ptree
, along with README.md there. @xray7224 and @dpino wdyt?