On Fri, 26 Mar 2010, SJS wrote: > > > 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.
matter of preferences. making bugs more severe (thus more apparent, thus discovered earlier) cheers me up a lot. if there was a magic `catch fire on every bug' knob, i'd be turning it way up. ultimately, for your (as in "those who use wm") benefit, i might add. > Do we actually have a problem with EINTR now? what does this have to do with correctness? do we have a problem with lost data? probably not, since we'd be all on fire by now otherwise. how come nobody is picking on (by the line of your argument "completely unnecessary") fsyncs? this is not even touching the question, do we actually have a problem, where? bsd-land? system v-land? linux-land? (afaik, for example, on linux, close isn't ever interrupted). > > > 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. and bike shed arguments are cheap. there have been and will be metric tons of bugs in the patches i submit, and all you can pick is a lousy MACRO NAME? for a macro nothing outside of file ops ever uses? > > 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. so maybe you just have not spent enough time staring at the code. > > 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'. there's a very fine line. but let's take a look at the glibc version, TEMP_FAILURE_RETRY. what does it do? retries. when do you need to need to retry something? when it failed in the first place. reduncancy #1. on what failures do you need to retry something? if it's a temporary failure. redundancy #2. all it does is make you *not think*. (putting aside the fact that it being a c library, it has to cater for pre-existing conditions, as in not to clash with names already most likely used, so they sort of had to pick something unique. this condition is not present in wm.) > [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. this is actually a good one. i'll be borrowing this argument, from time to time, if you don't mind ;) but then, beauty is subjective and culture-dependent. for now, since it's mostly me who shows attraction towards the girl, beauty is what i say it is. i am all for letting and even encouraging others to lay cinderella, so here's an irrevocable offer: for every calendar month you submit a patch that is eventually applied for which diffstat says affects at least, say, a hundred lines, you get to pick the name for this macro, and i will change it personally. this is called putting your money where your mouth is. talk is cheap, code isn't. this probably sounds offensive. it's sort of part of my nature. besides, if this is what wakes your pride and start submitting patches just to prove me wrong or make me feel bitten, that's a small price for me to pay, and in the end, wm wins. > > > > 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 don't know, don't care. all i care about is that it *was* interrupted, and it is *safe* to re-try. the fact that i don't understand unix signals (who does?) doesn't mean i can't (at least in several specific cases) use them. i don't understand macroeconomy either, yet i can still calculate a regular annuity. (probably... at gunpoint... it's been a while.) > signal. Or is there a problem with spurious signals? what do spurious signals have to do with this? there is a *documented* scenario that the call may return with eintr. all there is to care about is that it can be retried. *why* it returned with eintr is up to kernel folks. i don't know, i don't need to know, at this stage i don't want to know, and i don't care. i fail to see why is it so hard to see that this one specific case the test is for is a temporary condition, as opposed to be a fatal condition, would it be say ebadf or efault or whatever else. > Is this a security issue? no(t that i know of). it is an issue of not failing unless absolutely necessary. > > 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. this assertion is based on what, exactly? i am ready to accept it is, but you'll have to back it up with something more concrete than `because i said so'. why it is *not* is documented in the manual pages of the calls affected, and probably elsewhere (i'd so have liked to cite you from apue or the daemon book, but i keep them at work). > I'm not trying to say that you're _wrong_. I just want to be enlightened > by some means other than sarcasm and condescension. to be honest, you've come to the wrong place. sarcasm is my middle name. enlightenment is in signal(7) on linux, signal(3) on freebsd, somewhere around siginterrupt(3) on openbsd, sigaction(2) on solaris, various places on other systems, and i'm quite sure lots about the subject written up in apue still holds. -- [-] mkdir /nonexistent -- To unsubscribe, send mail to [email protected].
