Re: VMS patch set (extensive) - first try (almost)
[email protected] (Steven M. Schweda)
| Newsgroups | gmane.comp.web.wget.patches |
|---|---|
| Message-ID | <[email protected]> |
From: Hrvoje Niksic <[email protected]> > I wasn't joking about my reasons to introduce the flush, and I'm sorry > that you find them ridiculous. [...] Perhaps I exagerated a bit, but if the problem is with the progress message, then wouldn't a flush (and sync) before the message make more sense? And if the problem is with CTRL/C, then I'd be amazed if a flush would make much difference, especially a flush _without_ a sync (unless the built-in SIGINT handler does more than I'd expect). (Which could be, as I don't expect much from it. And, in any case, couldn't the CTRL/C arrive between the progress message and the flush()?) > Regardless of that, it was never my > intention to slow down anyone's download, and therefore I find it > perfectly acceptable that your VMS patches #ifdef it out. At the > moment I see no reason to remove the fflush on systems supported by > Wget mainline. Well, I'm _trying_ to get VMS onto that list. (It's not yet clear how well that's going.) It's probably worth a comment near the fflush() mentioning that it seems to matter little on at least a couple of UNIX (or UNIX-like) systems, but slows VMS significantly (instead of my longer rant). Explaining why it's there (instead of why it won't hurt) might also be helpful for the next guy (or at least give him a good chuckle). > For what it's worth, and removing the fflush doesn't make any > difference in download speed on Linux. (Tested with fast downloads > over the local network and from localhost.) Which agrees with my quick Tru64 test. ------------------------------------------------------------------------ Steven M. Schweda (+1) 651-699-9818 382 South Warwick Street sms@antinode-org Saint Paul MN 55105-2547