[Seaside] Re: Are Collections threadsafe?

[Adrian Lienhard]

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  
applications.

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.

Continuation currentDo: [ :cc |
   [ [ 1/0 ] ensure: [ Transcript show: 'ensure' ] ]
       ifError: [ cc value ] ].

Cheers,
Adrian