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,
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.
witty-interest mailing list

Reply via email to