Re: [Wt-interest] Wt with Qt - help
Hey Daniel, 2010/2/9 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: OK, you guys convinced me, I got rid of all my recursive event loops and now I do have Qt working inside of Wt. Please keep me posted if this issue gets fixed though as it was a non-trivial amount of effort to change all my code this way. I have finally come around to implement this -- it works in my development version and will be available in the next released version. Regards, koen -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
Hey Daniel, 2010/2/9 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: OK, you guys convinced me, I got rid of all my recursive event loops and now I do have Qt working inside of Wt. Please keep me posted if this issue gets fixed though as it was a non-trivial amount of effort to change all my code this way. Yes, it is unfortunate that this is possibly the only thing not working properly with our Qt integration. We are trying to come up with a solution ... Regards, koen -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
OK, you guys convinced me, I got rid of all my recursive event loops and now I do have Qt working inside of Wt. Please keep me posted if this issue gets fixed though as it was a non-trivial amount of effort to change all my code this way. One thing I did trip up on was that in order to get the Qt event loop I was using a QApplication which failed with fastcgi (worked with built-in httpd) because it couldn't connect to X server. Then I switched to QCoreApplication and it worked. An obvious problem in retrospect, but I thought I'd mention it in case anyone else gets tripped up on it. -- Dan On Feb 8, 2010, at 1:15 PM, Wim Dumon wrote: Hello Daniel, Don't forget to increase the amount of threads in your application if you're using show() intensively. Show() starts a local event loop, and every session that is waiting in such a local event loop occupies a Wt thread (Wt needs to keep the stack state somewhere until that local event loop returns. Normally, i.e. if you're not using local event loops, there is no stack associated with a session and Wt randomly assigns threads to handle requests). When all available server threads are locked by calls to show(), new requests can no longer be handled and therefore some user's interfaces will lock up until an other users closes his dialog. Calling show() is indeed easy, but it scales not as good. To avoid lockups at all cost, you must set the number of threads equal to the maximum number of concurrent sessions you want to handle. It depends on your situation if this is acceptable. You can change the amount of threads in wt_config.xml Regards, Wim. 2010/2/8 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: Hi Koen, Thanks for the detailed explanation. I suppose I could rewrite my code to do things this way. It wouldn't be so bad for a couple of the dialog boxes, but I also was relying quite heavily on WMessageBox::show() so replacing all of those calls with non-blocking dialogs is going to be pretty painful. I am tempted to just ditch Qt until this issue is fixed. I mainly was using it for QFileSystemWatcher, but it's beginning to not be worth all the trouble. -- Dan On Feb 8, 2010, at 10:06 AM, Koen Deforche wrote: Hey Daniel, 2010/2/8 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: Do you mean to make the dialog non-modal? Or is there some other way to execute a modal dialog other than using exec()? I would not be able to make the dialog non-modal, that would not work for my application. If there is some other way to execute a modal dialog, could you tell me how to do it? Yes, you can execute a modal dialog without using exec(). From http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WDialog.html: WDialog can be used as any other widget. In this case, the WDialog is simply instantiated as another widget. The dialog may be closed by calling accept(), reject() or done() (or connecting a signal to one of these methods). This will hide the dialog and emit the finished() signal, which you then can listen for to process the dialog result and delete the dialog. Unlike other widgets, a dialog does not need to be added to a parent widget, but is hidden by default. You must use the method show() or setHidden(true) to show the dialog. So, instead of exec(), use show(), and listen to the finished() signal instead of inspecting the result of exec(). This does mean that you cannot build your dialog on the stack, and for a complex dialog you will want to specialize WDialog to keep track of form fields. See for example FileEditDialog in TreeViewDragDrop.C (treeview-dragdrop example). In the mean-time we have been brainstorming about solutions to the original problem. One solution would be to not spawn a dedicated thread for each session, but instead make it so that a session is always handled by the same thread (by using a hash function on the session ID which hashes it on a thread from a thread pool). However, we currently do not see how this can be done in conjunction with our current asio design for wthttpd. Regards, koen -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest Daniel Ginsburg / email: daniel.ginsb...@childrens.harvard.edu Principal Software Architect Fetal-Neonatal Neuroimaging and Development Science Center Children's Hospital Boston 300 Longwood Avenue Boston, MA 02115 Phone:
Re: [Wt-interest] Wt with Qt - help
Hey Daniel, Although this fix seems to have partially fixed the problem, I am seeing an issue that I did not notice before. Now, when I create a modal WDialog and call the dialog's exec() I get a boost::lock_error exception thrown: We had not considered this, and indeed, this the exec() method starting the recurse eventloop is a problem, as it does not consider that it may be running from a different thread than the thread that was handling the incoming event. I fear the fix will not be trivial. Is it possible to use the non-exec() method of invoking the dialog as a workaround ? Regards, koen -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
Hello Daniel, Don't forget to increase the amount of threads in your application if you're using show() intensively. Show() starts a local event loop, and every session that is waiting in such a local event loop occupies a Wt thread (Wt needs to keep the stack state somewhere until that local event loop returns. Normally, i.e. if you're not using local event loops, there is no stack associated with a session and Wt randomly assigns threads to handle requests). When all available server threads are locked by calls to show(), new requests can no longer be handled and therefore some user's interfaces will lock up until an other users closes his dialog. Calling show() is indeed easy, but it scales not as good. To avoid lockups at all cost, you must set the number of threads equal to the maximum number of concurrent sessions you want to handle. It depends on your situation if this is acceptable. You can change the amount of threads in wt_config.xml Regards, Wim. 2010/2/8 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: Hi Koen, Thanks for the detailed explanation. I suppose I could rewrite my code to do things this way. It wouldn't be so bad for a couple of the dialog boxes, but I also was relying quite heavily on WMessageBox::show() so replacing all of those calls with non-blocking dialogs is going to be pretty painful. I am tempted to just ditch Qt until this issue is fixed. I mainly was using it for QFileSystemWatcher, but it's beginning to not be worth all the trouble. -- Dan On Feb 8, 2010, at 10:06 AM, Koen Deforche wrote: Hey Daniel, 2010/2/8 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: Do you mean to make the dialog non-modal? Or is there some other way to execute a modal dialog other than using exec()? I would not be able to make the dialog non-modal, that would not work for my application. If there is some other way to execute a modal dialog, could you tell me how to do it? Yes, you can execute a modal dialog without using exec(). From http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WDialog.html: WDialog can be used as any other widget. In this case, the WDialog is simply instantiated as another widget. The dialog may be closed by calling accept(), reject() or done() (or connecting a signal to one of these methods). This will hide the dialog and emit the finished() signal, which you then can listen for to process the dialog result and delete the dialog. Unlike other widgets, a dialog does not need to be added to a parent widget, but is hidden by default. You must use the method show() or setHidden(true) to show the dialog. So, instead of exec(), use show(), and listen to the finished() signal instead of inspecting the result of exec(). This does mean that you cannot build your dialog on the stack, and for a complex dialog you will want to specialize WDialog to keep track of form fields. See for example FileEditDialog in TreeViewDragDrop.C (treeview-dragdrop example). In the mean-time we have been brainstorming about solutions to the original problem. One solution would be to not spawn a dedicated thread for each session, but instead make it so that a session is always handled by the same thread (by using a hash function on the session ID which hashes it on a thread from a thread pool). However, we currently do not see how this can be done in conjunction with our current asio design for wthttpd. Regards, koen -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
Hi Koen,
Coming back to this problem:
I found the problem, and pushed a fix to public git. The following is
a patch which you could also apply on 3.1.0.
Regards,
koen
diff --git a/src/Wt/WResource.C b/src/Wt/WResource.C
index c960b25..df8876e 100644
--- a/src/Wt/WResource.C
+++ b/src/Wt/WResource.C
@@ -86,7 +86,7 @@ void WResource::handle(WebRequest *webRequest,
WebResponse *webResponse,
// lock
if (!continuation) {
WebSession::Handler *h = WebSession::Handler::instance();
-if (h)
+if (h h-lock().owns_lock())
h-lock().unlock();
}
#endif // WT_THREADED
Although this fix seems to have partially fixed the problem, I am seeing an
issue that I did not notice before. Now, when I create a modal WDialog and
call the dialog's exec() I get a boost::lock_error exception thrown:
0.17.24.201 - - [2010-Feb-03 10:16:51.291922] POST
/?wtd=YprzPnQp14Uuo2MYrand=36635 HTTP/1.1 200 0
[2010-Feb-03 10:16:51.293761] 10621 [/ YprzPnQp14Uuo2MY] [error] Error during
event handling: boost::lock_error
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.
terminate called after throwing an instance of 'boost::lock_error'
what(): boost::lock_error
Aborted
I am assuming this has something to do with the WDialog::exec() spawning a new
thread?
Any help/fix would be appreciated.
Daniel Ginsburg / email: daniel.ginsb...@childrens.harvard.edu
Principal Software Architect
Fetal-Neonatal Neuroimaging and Development Science Center
Children's Hospital Boston
300 Longwood Avenue
Boston, MA 02115
Phone: 857-218-5140
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
By the way, here is the callstack when the exception is thrown from
WebSession::doRecursiveEventLoop()
#0 0x749eb1c0 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1 0x77ad3436 in boost::unique_lockboost::mutex::unlock
(this=0x77dc80) at /usr/include/boost/thread/locks.hpp:371
#2 waitboost::unique_lockboost::mutex (this=0x77dc80) at
/usr/include/boost/thread/pthread/condition_variable.hpp:83
#3 Wt::WebSession::doRecursiveEventLoop (this=0x77dc80) at
/chb/users/ginsburg/Downloads/wt-3.1.0/src/web/WebSession.C:665
#4 0x7799d021 in Wt::WDialog::exec (this=0x7fffe1ff9a40) at
/chb/users/ginsburg/Downloads/wt-3.1.0/src/Wt/WDialog.C:214
#5 0x0048b793 in ScanBrowser::pipelineOverrideClicked (this=value
optimized out) at
/chb/users/ginsburg/workspaces/www/wt/src/pl_gui/ScanBrowser.cpp:418
#6 0x77a98fc3 in boost::signal1void, Wt::WMouseEvent,
boost::last_valuevoid, int, std::lessint, boost::function1void,
Wt::WMouseEvent ::operator()(Wt::WMouseEvent) () from
/usr/local/lib/libwt.so.19
#7 0x77a99750 in
Wt::EventSignalWt::WMouseEvent::processDynamic(Wt::JavaScriptEvent const) ()
from /usr/local/lib/libwt.so.19
#8 0x77ad01c6 in Wt::WebSession::processSignal (this=value optimized
out, s=0x77f9e8, se=value optimized out, request=value optimized out,
kind=value optimized out) at
/chb/users/ginsburg/Downloads/wt-3.1.0/src/web/WebSession.C:1438
#9 0x77ad711b in Wt::WebSession::notifySignal (this=0x77dc80, e=value
optimized out) at
/chb/users/ginsburg/Downloads/wt-3.1.0/src/web/WebSession.C:1412
#10 0x77ad7b8d in Wt::WebSession::notify (this=0x77dc80, event=...) at
/chb/users/ginsburg/Downloads/wt-3.1.0/src/web/WebSession.C:1183
#11 0x0049a54a in Wt::DispatchThread::doEvent (this=0x7fffe408ce20) at
/chb/users/ginsburg/workspaces/www/wt/src/pl_gui/lib/DispatchThread.C:150
#12 0x0049b251 in Wt::DispatchObject::qt_metacall (this=0x7b8070,
_c=QMetaObject::InvokeMetaMethod, _id=value optimized out, _a=value
optimized out) at
/chb/users/ginsburg/workspaces/www/wt/build/src/pl_gui/lib/moccedDispatchThread.C:70
#13 0x7613e0f9 in QObject::event(QEvent*) () from
/usr/lib/libQtCore.so.4
#14 0x76b09efc in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /usr/lib/libQtGui.so.4
#15 0x76b111ce in QApplication::notify(QObject*, QEvent*) () from
/usr/lib/libQtGui.so.4
#16 0x7612ec2c in QCoreApplication::notifyInternal(QObject*, QEvent*)
() from /usr/lib/libQtCore.so.4
#17 0x7612f80a in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib/libQtCore.so.4
#18 0x76157533 in ?? () from /usr/lib/libQtCore.so.4
#19 0x7276abce in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#20 0x7276e598 in ?? () from /lib/libglib-2.0.so.0
#21 0x7276e6c0 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#22 0x761571a6 in
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag) ()
from /usr/lib/libQtCore.so.4
#23 0x7612d532 in
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from
/usr/lib/libQtCore.so.4
#24 0x7612d904 in
QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) () from
/usr/lib/libQtCore.so.4
#25 0x760456cb in QThread::exec() () from /usr/lib/libQtCore.so.4
#26 0x0049a6c4 in Wt::DispatchThread::run (this=0x7fffe408ce20) at
/chb/users/ginsburg/workspaces/www/wt/src/pl_gui/lib/DispatchThread.C:69
#27 0x76048445 in ?? () from /usr/lib/libQtCore.so.4
#28 0x75dd4a04 in start_thread (arg=value optimized out) at
pthread_create.c:300
#29 0x741f97bd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#30 0x in ?? ()
On Feb 3, 2010, at 11:07 AM, Ginsburg, Daniel wrote:
Hi Koen,
Coming back to this problem:
I found the problem, and pushed a fix to public git. The following is
a patch which you could also apply on 3.1.0.
Regards,
koen
diff --git a/src/Wt/WResource.C b/src/Wt/WResource.C
index c960b25..df8876e 100644
--- a/src/Wt/WResource.C
+++ b/src/Wt/WResource.C
@@ -86,7 +86,7 @@ void WResource::handle(WebRequest *webRequest,
WebResponse *webResponse,
// lock
if (!continuation) {
WebSession::Handler *h = WebSession::Handler::instance();
-if (h)
+if (h h-lock().owns_lock())
h-lock().unlock();
}
#endif // WT_THREADED
Although this fix seems to have partially fixed the problem, I am seeing an
issue that I did not notice before. Now, when I create a modal WDialog and
call the dialog's exec() I get a boost::lock_error exception thrown:
0.17.24.201 - - [2010-Feb-03 10:16:51.291922] POST
/?wtd=YprzPnQp14Uuo2MYrand=36635 HTTP/1.1 200 0
[2010-Feb-03 10:16:51.293761] 10621 [/ YprzPnQp14Uuo2MY] [error] Error
during event handling: boost::lock_error
Qt has caught an exception thrown from an event handler.
Re: [Wt-interest] Wt with Qt - help
Hi Koen,
diff --git a/src/Wt/WResource.C b/src/Wt/WResource.C
index c960b25..df8876e 100644
--- a/src/Wt/WResource.C
+++ b/src/Wt/WResource.C
@@ -86,7 +86,7 @@ void WResource::handle(WebRequest *webRequest,
WebResponse *webResponse,
// lock
if (!continuation) {
WebSession::Handler *h = WebSession::Handler::instance();
-if (h)
+if (h h-lock().owns_lock())
h-lock().unlock();
This patch appears on my something might be wrong radar.
Is this not a classical race where the test for lock ownership
succeeds but the when the unlock is called the test condition is no longer
true because your thread got preempted?
Ok, I admit that I haven't looked at the locking protocol or the semantics
of your locking primitvies, so I might be wrong.
Kind regards,
Maurice
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
On Mon, Feb 1, 2010 at 8:48 PM, Koen Deforche k...@emweb.be wrote:
Hey Maurice,
2010/2/1 Maurice Gittens mainmanmauri...@gmail.com:
diff --git a/src/Wt/WResource.C b/src/Wt/WResource.C
index c960b25..df8876e 100644
--- a/src/Wt/WResource.C
+++ b/src/Wt/WResource.C
@@ -86,7 +86,7 @@ void WResource::handle(WebRequest *webRequest,
WebResponse *webResponse,
// lock
if (!continuation) {
WebSession::Handler *h = WebSession::Handler::instance();
-if (h)
+if (h h-lock().owns_lock())
h-lock().unlock();
This patch appears on my something might be wrong radar.
Is this not a classical race where the test for lock ownership
succeeds but the when the unlock is called the test condition is no
longer
true because your thread got preempted?
Not really, if the thread has the lock it has exclusive access ? I
cannot see why this could be a race condition ?
(WebSession::Handler::instance() returns an object from thread-local
memory which is entirely owned by the current thread).
Usually, a thread will have the session lock on entry of a WResource
handleRequest(), but there are a few exceptions. Resources are handled
outside of the session lock and are reentrant -- but still protected
against being destructed while busy, and therefore we want to release
the session lock if we have it.
The wtwithqt support library works by doing all event handling for a
particular session inside a dedicated Qt thread, since this is the
only way to work with Qt's threading model (which binds ownership of
QObjects to a particular thread and requires that only that thread
uses signal/slots on that object). In that case the Qt thread will not
have the session lock, but the Wt thread that is handling the session
will have the lock. Functionally, this means that when using Wt in
conjunction with Qt, WResource handling will not be reentrant.
As I said, I haven't looked at the locking protocol or the semantics
of your locking primitvies, so I might be wrong.
Thanks for your comments.
Kind regards,
Maurice
Regards,
koen
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
Hey Daniel, 2010/1/28 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu: I am trying to integrate Qt into my Wt application. I got the wtwithqt example to build and run no problem and I integrated the libwtwithqt.a into my project. I changed my application to inherit WQApplication and attempted to create a simple QtObject (like the one in the sample) in the virtual MyApplication::create() method. The problem I am having is that I am getting an exception: [2010-Jan-28 14:41:11.606307] 22371 [/ PmOcWEt6qjPLXZVP] [error] Exception while streaming resourceboost::lock_error It seems that it may have to do with using a WResource, and I can see what might be a small problem in that case because of the thread switching magic going on in the background. To be investigated ! Regards, koen -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
Hey Daniel,
2010/1/29 Koen Deforche k...@emweb.be:
Hey Daniel,
2010/1/28 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu:
I am trying to integrate Qt into my Wt application. I got the wtwithqt
example to build and run no problem and I integrated the libwtwithqt.a into
my project. I changed my application to inherit WQApplication and attempted
to create a simple QtObject (like the one in the sample) in the virtual
MyApplication::create() method. The problem I am having is that I am
getting an exception:
[2010-Jan-28 14:41:11.606307] 22371 [/ PmOcWEt6qjPLXZVP] [error] Exception
while streaming resourceboost::lock_error
It seems that it may have to do with using a WResource, and I can see
what might be a small problem in that case because of the thread
switching magic going on in the background. To be investigated !
I found the problem, and pushed a fix to public git. The following is
a patch which you could also apply on 3.1.0.
Regards,
koen
diff --git a/src/Wt/WResource.C b/src/Wt/WResource.C
index c960b25..df8876e 100644
--- a/src/Wt/WResource.C
+++ b/src/Wt/WResource.C
@@ -86,7 +86,7 @@ void WResource::handle(WebRequest *webRequest,
WebResponse *webResponse,
// lock
if (!continuation) {
WebSession::Handler *h = WebSession::Handler::instance();
-if (h)
+if (h h-lock().owns_lock())
h-lock().unlock();
}
#endif // WT_THREADED
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
Re: [Wt-interest] Wt with Qt - help
Hi Koen,
I made this fix in my Wt 3.1.0 code branch and it fixed the problem! As usual,
thanks for your awesome support.
-- Dan
On Jan 29, 2010, at 4:11 AM, Koen Deforche wrote:
Hey Daniel,
2010/1/29 Koen Deforche k...@emweb.be:
Hey Daniel,
2010/1/28 Ginsburg, Daniel daniel.ginsb...@childrens.harvard.edu:
I am trying to integrate Qt into my Wt application. I got the wtwithqt
example to build and run no problem and I integrated the libwtwithqt.a into
my project. I changed my application to inherit WQApplication and
attempted to create a simple QtObject (like the one in the sample) in the
virtual MyApplication::create() method. The problem I am having is that I
am getting an exception:
[2010-Jan-28 14:41:11.606307] 22371 [/ PmOcWEt6qjPLXZVP] [error] Exception
while streaming resourceboost::lock_error
It seems that it may have to do with using a WResource, and I can see
what might be a small problem in that case because of the thread
switching magic going on in the background. To be investigated !
I found the problem, and pushed a fix to public git. The following is
a patch which you could also apply on 3.1.0.
Regards,
koen
diff --git a/src/Wt/WResource.C b/src/Wt/WResource.C
index c960b25..df8876e 100644
--- a/src/Wt/WResource.C
+++ b/src/Wt/WResource.C
@@ -86,7 +86,7 @@ void WResource::handle(WebRequest *webRequest,
WebResponse *webResponse,
// lock
if (!continuation) {
WebSession::Handler *h = WebSession::Handler::instance();
-if (h)
+if (h h-lock().owns_lock())
h-lock().unlock();
}
#endif // WT_THREADED
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
Daniel Ginsburg / email: daniel.ginsb...@childrens.harvard.edu
Principal Software Architect
Fetal-Neonatal Neuroimaging and Development Science Center
Children's Hospital Boston
300 Longwood Avenue
Boston, MA 02115
Phone: 857-218-5140
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
