-
Notifications
You must be signed in to change notification settings - Fork 48
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
Multithread in ruby-dbus #7
Comments
Sorry to interrupt. Does your multithreading-implementation aim such a feature as well? |
Hi flagos, hurray, thanks for offering the help with threads. The approach looks reasonable to me, however, I don't consider myself knowledgeable enough around concurrency and thread safety. I'll read up and ask around. As this deserves a broader discussion, why don't we continue on the mailing list? Please go ahead, but remember to include test cases. They don't have to be perfect, just a sample of code that somehow fails with the current library. Martin |
Status: some stalled attempts to solve this, from Jaunary 2011, are in https://github.com/mvidner/ruby-dbus/tree/multithreading |
The previous attempt at thread safety failed (#7, #73) but now I see a limited use case: A worker thread only uses the shared bus connection to send signals about its progress and completion. No method calls are accepted there. That is, we only race for the bus connection in MessageQueue#push, not in the #pop reading part.
The previous attempt at thread safety failed (#7, #73) but now I see a limited use case: A worker thread only uses the shared bus connection to send signals about its progress and completion. No method calls are accepted there. That is, we only race for the bus connection in MessageQueue#push, not in the #pop reading part.
Hi,
We quite need for our project to use ruby-dbus multhreaded. This feature is not supported as reported in 20 - 21 -22. We are thinking about an implementation and we want to have an enlightened opinion before coding it.
The problem seems to be due to update_buffer function and IO.select. Update_buffer function doesn’t know from which does come the previous request and the first thread that take IO.select income takes the request. A way to solve it may be to dedicate a thread that wait IO.select and return the buffer to the according thread:
if message-type is METHOD_CALL or SIGNAL, return to main thread.
if MESSAGE_RETURN, return to concerned thread. To do so, we need when sending a message to log in a hash (for example) the thread it cames from.
The thread will wait a Thread.stop and will be restarted from the dedicated one with a Thread.run
Do you agree with this implementation, do you see limitations from that ?
The text was updated successfully, but these errors were encountered: