On 24/10/05, Sandy McArthur <[EMAIL PROTECTED]> wrote:
> On 10/23/05, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> > are there any pool developers out there with time to pick this up?
> >
> > otherwise, we could probably do with a volunteer to go through and
> > analyse these issues. anyone fancy taking a crack at this?
>
> I'm not a pool dev but I'll make some time to implement fixes for the
> problems Mayur Naik found and submit patches.
>
> While I'm at it would it be desirable to transition to the privately
> head lock idiom to defend against intentionally malicious code? eg to
> defend against:
>
> synchronized (aPool) {
> Thread.sleep(Integer.Max_Value);
> }
>
> by making anything that synchronized on this synchronize on a private field.
>
+1 If possible, but one cannot always do this.
If a class is conditionally thread-safe, i.e. it needs external
synchronisation - then the appropriate lock object must be made
available to clients. E.g. HashTable needs external synch for its
Iterator [Bloch, Item 52]
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
