Bill,
Thanks for the response.
Lloyd
On Jan 22, 2007, at 12:02 AM, Bill Shannon wrote:
> Lloyd L Chambers wrote:
>> Bill,
>> I ask the following because the response I'm getting for having
>> filed about 40 GlassFish thread-safety bugs as P2 today has been
>> neutral at best. All of them are easy to fix (most are the null-
>> check idiom).
>> I can't say whether they currently cause a problem, on what OS or
>> system they might cause a problem, or even whether they'll *ever*
>> cause or have caused a problem. But I can say there is an effort
>> underway to thread GlassFish startup code, and that the code for
>> most of these will be run at startup. I can also say I had to back
>> out some changes I committed last Friday which mysteriously passed
>> on two Mac OS X machines, but failed on Linux and Solaris--and I
>> can't explain why.
>> 1) If you came across a thread-safety issue, at what level would
>> you file it? P1, P2, P3, P4?
>
> There isn't a simple answer to this question.
>
> In general, I would probably file thread safety bugs as P3, but
> there are
> exceptions that could go higher or lower.
>
>> 2) Would it depend on *when* it was found (eg just before beta)?
>
> Generally I don't modify bug priorities based on when during the
> release
> cycle the bug is found. Per normal Sun bug priority definitions, the
> bug priority essentially tells you when the bug should be fixed. P3
> needs to be fixed before FCS (final release).
>
>> 3) Would the level depend on whether you could *prove* it was
>> actually resulting in a reproducible bug?
>
> Yes. That would certainly increase the priority.
>
>> 4) Would it be acceptable to ship thread-unsafe code to a
>> customer without knowing the answers to the above, especially if
>> the fix is trivial?
>
> I think the big qualifier is "the fix is trivial". I've made trivial
> fixes that turned out to have unforeseen consequences, so some caution
> is called for. But, in general, and especially earlier in a release
> cycle, I would err on the side of fixing such bugs.
>
>> We have been filing P2 bugs for performance improvements. I am
>> troubled by the idea that a correctness bug can be a lower
>> priority than a minor performance improvement goal. The unknown
>> and unquantifiable risk of a thread-safety bug is compelling
>> enough for me to make it a P2.
>> I would appreciate your thoughts. If you would like to cc
>> dev_at_glassfish, that is OK with me. Or if you prefer a private
>> response, that's OK too.
>> Lloyd
>
> There's a lot of "it depends" in all of this.
>
> When running FindBugs on the JavaMail code that I maintain, it found a
> number of places where fields are only protected by locks some of the
> time. In general, these are just accidents waiting to happen, and it
> scares me. But, in most cases, the problems are in code that hasn't
> changed in many years and such problems have never occurred in
> practice
> (to my knowledge, of course). These are the kinds of bugs I would
> consider
> to be P4 or lower. The risk of fixing such bugs in otherwise
> stable and
> tested code is greater than the risk of the bug actually occurring.
>
> No bug fix is risk free, and sometimes the probability of breaking
> something while fixing the bug is greater than the probability of the
> bug actually occurring.
>
> In cases where I judge the risk to be too great, I often add a comment
> to the code describing the problem and the risk, in case I decide in
> the future that the fix is less risky or the bug more likely.
>
> Hope that helps.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>