Project

General

Profile

multithreading

Added by Christophe Delépine over 13 years ago

Hello,

my Wt application is started with ---threads=1

so 2 threads are active :

  • the main wt thread (the one that calls WRun)
  • the session thread (the one that executes signal/slot code) that is created by the main thread

1/ does the session thread inherit the same cpu affinity and thread priority as the main thread ? If not, is it possible to force them by program ?

2/ is it possible to modify the widget tree from a third (application) thread rather than from the session thread ? one use case would be to update a text widget whose value changes dynamically in the application. if not, how can i send messages to the session thread from my application thread ?

regards

Christophe


Replies (6)

RE: multithreading - Added by Wim Dumon over 13 years ago

1. Wt does not set/modify any thread priorities. See code in src/http/WServer.C, in WServer::start()

2. Yes, provided that you acquire the widget tree update lock. See WApplication documentation (updatelock) and the serverpush example at examples/feature/serverpush/

Regards,

Wim.

RE: multithreading - Added by Christophe Delépine over 13 years ago

Hello Wim,

Is it possible to disable WT_THREADED symbol in wt projects in order to have one single wt thread instead of 2 ?

When a signal is triggered, the thread that executes the signal-slot code needs to send messages to my application threads. In order to do that, the thread must have been created by our API (we have our own Thread class).

Thanks

RE: multithreading - Added by Wim Dumon over 13 years ago

Christophe,

Sure, that is possible. Set the MULTI_THREADED option while configuring Wt in cmake to 'OFF' (DMULTI_THREADED=OFF, or uncheck the checkbox in the cmake gui). That mode was introduced to allow Wt to be compiled on platforms without proper threading support> no threads, no locks, ... You loose features such as nested event loops (the .exec() method of modal dialogs) and the (yet to be released) new WSocketNotifier. Also, I don't think there's a safe way to modify the widget tree from a separate thread anymore, as getUpdateLock() is unable to guarantee exclusive access to the widget tree (for the lack of locking primitives). So I'm not sure if this is still an acceptable solution for your situation.

Alternatively, you may use a (variation of) the trick demonstrated in the wtwithqt example. Qt doesn't allow neither to invoke signal handlers from just any thread. In that example, every session creates a QThread, and a simple thread switch executes the entire event handling of Wt events in the QThread.

BR,

Wim.

RE: multithreading - Added by Christophe Delépine over 13 years ago

Wim,

I have unchecked MULTI_THREADED in cmake gui but now Wt does not compile anymore :

1. WServer::restart calls a unix method (execve) which is not defined in windows. I have commented the lines out.

  1. boost/config/requires_threads.hpp complains : fatal error C1189: #error : "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS". Do i have to reconfigure boost ?

Thanks for your help

Christophe

RE: multithreading - Added by Christophe Delépine over 13 years ago

Wim,

I have finally managed to compile Wt with MULTI_THREADED set to OFF !

The 2nd error was in fact coming from wtisapi project. Since i don't need the ISAPI connector, i got rid of it in cmake gui by unchecking CONNECTOR_ISAPI

Regardings the 1st error, hopefully you will correct it in the future, but it is not a problem for me.

My signal-slot code now runs in the thread which i have created in my application, so all is fine.

I am aware that i will no longer be able to modify the widget tree from another thread but i can live with this limitation i guess.

I think it should be possible to expose a virtual 'WApplication::createThread' method to let the application create the threads that are needed by Wt. This way, we would not have to use "dirty" tricks as in wtwithqt. Do you think it could be implemented in the future ?

regards

Christophe

RE: multithreading - Added by Wim Dumon over 13 years ago

You're right, there's a problem with non-multithreaded builds on Windows. The fixes will be in the git repository soon (and in the next release).

The patch is attached hereto. There's no point in trying to support ISAPI without thread support, so I disabled it completely.

I created a feature request (#491) for your suggestion.

    (1-6/6)