Skip to content
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

Service framework improvements #213

Closed
dw opened this Issue Apr 24, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@dw
Copy link
Owner

dw commented Apr 24, 2018

This is just to track the increasing number of changes that might be nice to roll into service.py.

  • Add CALL_SERVICE reserved handle and parent.Context.service_call() method, eliminating the nasty mitogen.service.call() interface that currently requires pulling in an increasingly huge import.
  • First time CALL_SERVICE is invoked, target context pulls in the service framework code
  • Replace fixed handles with string names. Don't call by ansible_mitogen.services.FileService.handle, call "ansible_mitogen.services.FileService".
  • Add autoactivation. If CALL_SERVICE received for unknown class, attempt to automatically import and instantiate it, along with a per-context thread pool (possibly with some kind of whitelist, or possibly only if the request comes from a parent)
  • Give Service class a private Select() instance, and have the service pool subscribe that select to its own select. when any receiver for a service gets a message, the message is dispatched on a pool thread just like a method call would be, and the set of receivers for a service can grow and shrink as desired
  • Make service.Pool shutdown happen automatically in response to the associated Router/Broker shutdown.

All the above would remove a bunch of setup/teardown code from the Ansible extension that would need to be pretty much cutpasted into every future consumer, and would also allow e.g. FileService to run in reverse, without explicitly setting up a service pool via function calls in the target context.

It would also make a nice basis for building the debugger -- rather than hard-wiring a weird DEBUG handle, we could simply implement a "mitogen.debug.DebuggerService" that reuses all the thread pool code that potentially already exists in the target

dw added a commit that referenced this issue May 28, 2018

issue #213: core: have Message.reply() log msg for zero reply_to
It's easy to call msg.reply() by accident on a message that never had
reply_to set, resulting in a "invalid handle" error message coming from
router. Instead log a more accurate message on the stack that actualy
caused the problem.

dw added a commit that referenced this issue May 28, 2018

issue #213: use import_module() in parent.py.
This dynamic import crap really needs to be ripped out of parent.py
again. Static imports work much better for the module loader too.

dw added a commit that referenced this issue May 28, 2018

dw added a commit that referenced this issue May 28, 2018

dw added a commit that referenced this issue May 28, 2018

@dw dw closed this in 3b0addc May 28, 2018

dw added a commit that referenced this issue Jun 7, 2018

issue #213: avoid service.Pool construction race
Ensure concurrent calls to service.Pool do not result in a duplicate
pool being constructed in a child.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.