[hunchentoot-devel] thread safety in session-value

[Anton Vodonosov]

on Thursday, September 4, 2008, 10:37:39 PM Edi wrote:

> On Thu, 4 Sep 2008 06:47:38 +0200, "Hans Hübner" <hans at huebner.org> wrote:

>> I agree, this could be a problem if one session is accessed by
>> multiple requests, and this is not a completely unlikely scenario
>> (although I have not been bitten by this).  Do you have a patch?

> I don't think this needs a patch.  There's a lock for the case that
> Hunchentoot accesses the global session database.  If you (as a user)
> write an application where different handlers or different threads
> work on the same session object at the same time, then you know what
> you're doing and you should take care of locking (if needed) yourself.
> IMNSHO it is a bad decision to defensively wrap locks around
> everything that could in theory be accessed simultaneously.

Yes, such a contract may be used too, although in this case it looks to
me that user must take care of locking in virtually 100% of cases -
even single handler may be called from different threads for the
same session. And btw this is unexpected clarification to session
functions behavior, at least for me.

In fact my attention to this question was drawn by the fact
that (SETF (SESSION-VALUE )) uses lock, but other functions
do not. And the condition that aimed to be protected by the
lock in (SETF (SESSION-VALUE )) may potentially be broken
by concurrent DELETE-SESSION-VALUE.

Best regards,
-Anton

P.S.
If you wonder why am I poking in the hunchentoot code - I am
studying how session keys are generated in hope to find an
example of secure random value generation to use it in cl-openid.