[Seaside] Re: Are Collections threadsafe?

[Philippe Marschall]

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

Wow, I feel really stupid now.  And all those unwind-protect vs.
call-cc wars in Scheme vs. CommonLisp come to my mind.

Philippe

>  Continuation currentDo: [ :cc |
>    [ [ 1/0 ] ensure: [ Transcript show: 'ensure' ] ]
>        ifError: [ cc value ] ].
>
>  Cheers,
>
> Adrian
>
> _______________________________________________
>  seaside mailing list
>  seaside at lists.squeakfoundation.org
>  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>