begin quoting Tamas TEVESZ as of Fri, Mar 26, 2010 at 11:59:25PM +0100: > On Fri, 26 Mar 2010, SJS wrote: [attribution lost] > > > Using this RETRY() macro is a bit ugly. I didn't like from the look > > > of it. > > > > Shouldn't there also be some sort of limit in the loop? If the > > function so wrapped manages to have a bug that results in it causing > > itself to be interrupted, this construct turns into an infinite loop. > > i'm not following. why on earth would you want to hide a bug?
I don't see that as hiding. Making bugs /more/ severe (a feature doesn't work -> infinite loop) bothers me a lot. Do we actually have a problem with EINTR now? > > RETRY_ON_EINTR seems like a better name. Still ugly, though. > > it's ugly in it's original form, and you make it more ugly. good > strategy :) SINCE_EINTR_IS_NOT_FATAL_FOR_THIS_CODE_LOOP_IF_IT_HITS is > even less surprising... Moderation, friend. Moderation. Too short is bad, as is too long. Arguing against moderation by holding out an extreme as a counter-example is ... childish. > to some extent i see your point, but i'm trying to reduce eye > bleeding, not add to it, and that sometimes means you have to look > things up. Not seeing the reduction in eye-bleeding just yet. > have you ever seriously thought about `_'? shall we replace Oh, god, yes. > that with GETTEXT_OR_RAW_ARGUMENT? because that's what it does. No, I'd prefer to look for a third alternative. > how's my macro called? RETRY. what does it do? retries. what? go look. > if it was instead randomly deleting your files, i would agree we have > a problem. 'Succinct' is not always the same thing as 'terse'. [chop] > still think mine is ugly? Yes. The fact that it could be a lot uglier is irrelevent. Cinderella wasn't beautiful because her stepsisters were uglier. > > > The old code didn't retry, why do you need it now? > > > > Are signals really causing problems? Ignoring a signal errors seems > > like a bad policy, especially when it's hidden in a macro. > > this is not _ignoring_ it. this is _handling it_ by performing a > possible action: retrying the op. Why was the op interrupted? Retrying the op ignores the intent of the signal. Or is there a problem with spurious signals? Is this a security issue? > ignoring is what the original code does. ...and the code *still* needs to check the returned value for NULL anyway, in case the error was something other than EINTR. All you lose at that point is the retry, which is of dubious value. I'm not trying to say that you're _wrong_. I just want to be enlightened by some means other than sarcasm and condescension. -S. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
