Hi David,
Yes, we use the library in a multithreaded app on solaris (among other platforms). I consciously did not put any explicit threading support into the library itself because I didn't want to impose the overhead for apps that don't require it.
What I did was subclass the relevant classes and implement the threading support in the subclass. For instance, if a client (XmlRpcClient) is to be shared among multiple threads, the execute method needs to be protected as it is not re-entrant, so my subclass acquires a mutex, then calls the superclass implementation.
It would be possible to make the client code thread-safe by implementing the execute method in a non-blocking manner, but that wasn't necessary for my app so it didn't get done. In many situations, it would be easier for each thread to simply create its own client object since they are so lightweight.
Another potential area for thread support is in the server, where you might wish to distribute server connections among a pool of worker threads. I have not attempted this yet (again, no need for it in our app), but the best approach would seem to be to distribute a dispatcher object (XmlRpcDispatch) to each thread in the pool. When a new server connection is created and assigned to a thread, its source (the socket file descriptor) is added to the dispatcher for that thread. The modifications seem to be pretty straightforward: subclass the server to maintain a collection of dispatchers (one per worker thread) and to do the task allocation to threads, and subclass the dispatcher to serialize access to add/remove sources. Of course, everything sounds easy if you don't intend to do it :)
Hope this helps,
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Have you looked at mult-threading xmlrpc++ on Solaris?
Thanks,
David
Hi David,
Yes, we use the library in a multithreaded app on solaris (among other platforms). I consciously did not put any explicit threading support into the library itself because I didn't want to impose the overhead for apps that don't require it.
What I did was subclass the relevant classes and implement the threading support in the subclass. For instance, if a client (XmlRpcClient) is to be shared among multiple threads, the execute method needs to be protected as it is not re-entrant, so my subclass acquires a mutex, then calls the superclass implementation.
It would be possible to make the client code thread-safe by implementing the execute method in a non-blocking manner, but that wasn't necessary for my app so it didn't get done. In many situations, it would be easier for each thread to simply create its own client object since they are so lightweight.
Another potential area for thread support is in the server, where you might wish to distribute server connections among a pool of worker threads. I have not attempted this yet (again, no need for it in our app), but the best approach would seem to be to distribute a dispatcher object (XmlRpcDispatch) to each thread in the pool. When a new server connection is created and assigned to a thread, its source (the socket file descriptor) is added to the dispatcher for that thread. The modifications seem to be pretty straightforward: subclass the server to maintain a collection of dispatchers (one per worker thread) and to do the task allocation to threads, and subclass the dispatcher to serialize access to add/remove sources. Of course, everything sounds easy if you don't intend to do it :)
Hope this helps,
Chris
Thanks for this.
I was thinking of multi-threading on the server side. I'll see how I get on.
Cheers,
David
Well, you're not the only one. The core class code is great so I really don't like to re-hack it too much to get it multi-threaded...