| Jim Gallacher 2005-04-09, 8:45 pm |
| Nicolas Lehuen wrote:
> On Apr 9, 2005 3:00 AM, Jim Gallacher <jg.lists@sympatico.ca> wrote:
>
>
>
> Given the fact that getting the session object holds a lock for the
> whole duration of the request (from the session instantiation to the
> request cleanup), the locking code I've wrote in FileSession.do_load
> is redundant. What I don't understand, though, is why I didn't see any
> deadlock when I tested the code, whereas you see one. I assumed that
> the APR locking facility was reentrant, but maybe it's not. Or maybe
> it's reentrant on Win32 with threads, and not in an over environment.
On further consideration, maybe I'm using the term deadlock incorrectly
here. There are not 2 processes trying to acquire the lock, rather one
process trying to acquire the same lock twice, once for the session and
once for the file access. The second attempt blocks forever so the
request can't complete and the lock for that session is never released.
Subsequent requests for that session should fail, since the lock is
still held by that first, blocked request. And I don't understand why
it's not a problem in the threaded model as it seems to be in the
prefork model.
> Anyway... let's get rid of this redundant locking code in FileSession
> and the problem will be solved. The only problem, as Grisha pointed
> out, is that locking is an optional feature, you can disable it by
> passing lock=0 in the session constructor call. If locking is
> disabled, there is a potential for trouble in FileSession. For now,
> I'll just say that if you want to disable locking, then you know what
> you are doing...
Explicit is better than implicit and I don't like suprises. So maybe use
2 different locks?
Session lock:
_apache._global_lock(self._req.server, self._sid)
File lock:
_apache._global_lock(self._req.server, 'file_%s' % self._sid)
> As for MODPYTHON-31, as Graham noted in the comments, it looks like a
> problem in the reporter's configuration file. I've closed the bug
> report.
I didn't look at it really closely, but saw some similarities - a
request acquires a session lock but goes into an infinite loop and so
never releases the lock. I assume the browser will eventually time out
and drop the connection. How does apache handle this internally? Does
the registered cleanup code still get a chance to run and release any
locks?
Regards,
Jim
|