[Seaside] Re: Are Collections threadsafe?
philippe.marschall at gmail.com
Wed Feb 27 12:14:07 UTC 2008
2008/2/27, Adrian Lienhard <adi at netstyle.ch>:
> On Feb 27, 2008, at 08:22 , Andreas Raab wrote:
> > [...]
> > I'm not sure what point you're trying to make here but this is
> > actually a great example for what I mean. Lukas gave meaningful
> > information in this exchange and as a result we developed a couple
> > of theories and disproved them based on available evidence:
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-December/123047.html
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-December/123499.html
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-December/123511.html
> > I'm not claiming that you will *always* get to a result that
> > satisfies your needs but the above is a great example for the kind
> > of discourse that you can engage in when you provide some actual
> > data. Also, I think we both learned something in this exchange which
> > is where the real value lies - if I ever happen to run into a
> > similar situation the data that Lukas gave will definitely be
> > helpful in tracking this down. And don't worry, we'll get to it but
> > these are hard problems and I think we simply haven't got enough
> > data to determine the root cause of the problem. So if you have more
> > evidence, please share it and please don't be shy to post repeatedly
> > because that's what is needed to fix it.
> Here you are ;)
> Yesterday, I just happened to see again a Seaside application not
> responding anymore because a mutex was locked forever. However, no
> process was within the critical section that would eventually signal
> the semaphore. We had this problem before with SqueakSource and other
> After some investigations (and first blaming concurrency issues with
> semaphores), I found the following cause. If there is an exception
> thrown within the critical section but this exception is not caught by
> the application but by the Seaside error handler, then the Seaside
> error handler would generate an error page and return this to the
> user. The error handler calls WASession>>returnResponse:, which
> evaluates the session's escape continuation. Surprisingly, however,
> the continuation does not execute any unwind blocks when terminating
> the current stack (see Continuation>>terminate:). Obviously this is
> the reason why the semaphore of the mutex never gets signaled.
Wow, I feel really stupid now. And all those unwind-protect vs.
call-cc wars in Scheme vs. CommonLisp come to my mind.
> Continuation currentDo: [ :cc |
> [ [ 1/0 ] ensure: [ Transcript show: 'ensure' ] ]
> ifError: [ cc value ] ].
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside