Inline, this time...
On 20 December 2013 06:47, Peter <j...@zeus.net.au> wrote: > ----- Original message ----- > > On 12/19/2013 12:16 PM, Greg Trasuk wrote: > <SNIP> > > And, using, for example, the strategy you describe of constructing > > another object, code can be perfectly valid without using Startable. I > > see value in offering the interface, and a rule that the start method > > will be called after the constructor for any service implementing it. I > > don't think River should assume code is not safe just because it does > > not use that feature - it may be safe for entirely different reasons. > > > > In River's case, every service was constructed unsafely, period, no > exceptions, in fact the likelihood of not needing it is low, yes there are > alternate methods including not using final fields, but they are cumbersome > and unfriendly, there be dragons and only hacker knights would dare tread. > I offer thee this magic sword with which to slay your dragon. No really, > it's a fine sword... > Constructed unsafely as observed by what or whom? Simplistically, the point at which this gets multi-threaded on your ass is when you kick into life an SDM or JoinManager. Although you can use SDM in a single-threaded way for sure. JoinManager though, that's the dangerous puppy cos it makes your service reference visible to the world and thus leaves it open to being invoked concurrently. > But as Dan suggests, it isn't my job to stop people cutting themselves, > (Dan, put those scissors down now!) so people are free not to use it and I > have decided to reduce logging to FINE so you can switch it off if it > annoys you. Ironically that bug you can't sort will mysterously disappear > when you turn logging back on as that irritating message about safe > construction confronts you. > There are no scissors, the JMM does not dictate one must use finals to achieve thread safety. It's one option with caveats, there are others with different caveats. They all have sharp edges, it's a question of which tools you're comfortable with. Me, I like final, it has its uses but it is not the god of fault free multithreaded code. > > For other cases where using such an interface would have broken backward > compatibility, I had to create an abstract superclass with a stateless > subclass to ensure I had safe construction. > > See LookupDiscoveryManager and its abstract superclass in qa_refactor for > an example. I had to get advice from the concurrency interest list to > solve that one. > > You know JoinManager's private classes were synchronizing on their own > object locks to access their outer classes state? Oops! > > Those are bugfixes that fall in line with the original specifications/api docs, thus they are a different beast/class of issue. Go ahead, fix 'em, it's progress for sure. Make no mistake though, what you're asking to vote on is a different beast. > You are a passionate sort with your strengths and weaknesses, like > everybody, I do enjoy our conversations and could listen while you go blue > in the face explaining why we should love and preserve our existing code, > in all its buggy glory. Please stop now and read the code and do some > research before making any more comments to preserve any credibility that > remains. > > If you're worried about my code, you should be much more worried about the > existing, can it weather the oncoming muticore cyclone (Australian for > hurricane)? > > How many cores did you have in 2003 son? > > One more vote, c'mon at least one for my sense humour? Dan? > I don't vote on humour, waste of a vote. I'll give you my vote for this change but not until you put down the baseball bat (see my other emails). No, I mean it, I have no problem with your revised proposal but the tone of your pitch, not liking that so much. > > No takers? Oh well... > > Merry Christmas, > > Peter. > > > > (c) even where there is an apparent problem, the exposure window is > > very small. > > > > Remember an exposure window can be small in terms of numbers of > > statements, but long in terms of elapsed time. Leaving apparently small > > windows open can result in code that fails mysteriously, for example > > when a page boundary happens to fall in the window, and the system is > > under memory pressure. > > > > Patricia > >
