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

Support other Jeepney I/O options? #9

Open
takluyver opened this issue Nov 22, 2020 · 3 comments
Open

Support other Jeepney I/O options? #9

takluyver opened this issue Nov 22, 2020 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed
Milestone

Comments

@takluyver
Copy link
Contributor

At present, dbus_objects.integration.jeepney uses the jeepney 'blocking' I/O - which is suitable for a single thread, and nothing else can happen in that thread while it's serving requests.

One aim of Jeepney is to make it relatively easy (little extra code) to integrate with different I/O frameworks. Would you be interested in exploring how this would work in practice for dbus-objects?

In practical terms, all of the other I/O options (threading, asyncio, Trio) would let multiple tasks/threads handle requests on the same connection - although this only makes sense if the handlers do something slow which allows running another task while they wait. The asyncio & trio options can also integrate neatly into applications which use those frameworks.

@FFY00 FFY00 added enhancement New feature or request help wanted Extra attention is needed labels Nov 22, 2020
@FFY00
Copy link
Owner

FFY00 commented Nov 22, 2020

Yes, definitely. dbus-objects is written to be backend agnostic. The blocking factor right now is time.

I will probably work on adding support for signals and properties before I start adding more backend options, as I feel that is more relevant, but I am definitely happy to receive contributions 😊

@takluyver
Copy link
Contributor Author

I can relate to being limited by time. :-) As and when I have some to spare, I might start investigating what this would take.

@FFY00 FFY00 added this to the 0.0.3b1 milestone Nov 23, 2020
@FFY00
Copy link
Owner

FFY00 commented Nov 24, 2020

I have refactored the decorator code, we now use object descriptors. I have only played with async a bit, so I am not too comfortable with it, but it looks to me like normal methods should already be compatible, as we never modify the object passed into the decorator, we just store it in the descriptor object. I think we should be able to just fetch the object and call it with async context in the dispatch backend.

The only place that needs to gain support for this is dbus_property, I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants