From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Cedric Ware <cedric.ware__bml@normalesup.org>
Cc: dana <dana@dana.is>, zsh-workers@zsh.org
Subject: Re: [PATCH] Enable sub-second timeout in zsystem flock
Date: Sun, 15 Mar 2020 16:54:10 +0000 [thread overview]
Message-ID: <20200315165410.GA30241@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <20200315160324.dstgtmajzwxpaccn@phare.normalesup.org>
Cedric Ware wrote on Sun, Mar 15, 2020 at 17:03:24 +0100:
> Daniel Shahaf (Sunday 2020-03-15):
> > Cedric Ware wrote on Sat, 14 Mar 2020 22:04 +0100:
> > > +++ zsh-5.8/Doc/Zsh/mod_system.yo 2020-03-08 18:39:32.672683779 +0100
> > > @@ -166,7 +166,7 @@
> > > printed in the last case, but the parameter tt(ERRNO) will reflect
> > > the error that occurred.
> > > )
> > > -xitem(tt(zsystem flock) [ tt(-t) var(timeout) ] [ tt(-f) var(var) ] [tt(-er)] var(file))
> > > +xitem(tt(zsystem flock) [ tt(-t) var(timeout) ] [ tt(-i) var(interval) ] [ tt(-f) var(var) ] [tt(-er)] var(file))
> > > item(tt(zsystem flock -u) var(fd_expr))(
> >
> > Please s/var(var)/var(interval)/ in the body paragraphs of the item()().
>
> I don't understand. Option -f's parameter is actually called "var".
> The only occurrences of "var(var)" here are about -f, I didn't add them.
My bad; I'd misread the diff. Sorry for the noise.
> > > + timeout_tmp = timeout_param.u.d * 1e6;
> > > + if ((timeout_tmp < 1) || (timeout_tmp > ZLONG_MAX / 2)) {
> > > + zwarnnam(nam, "flock: invalid timeout value");
> >
> > I think the invalid value should be included in the error message,
> > either as a number, or as a string if needed: "flock: invalid timeout
> > value: '%s'".
>
> Done, but it had to be as a string, because I didn't see a way to use
> a zlong in zwarnnam().
That doesn't seem to be supported. It could be added, if needed.
> > dana, I see you advocated the opposite approach in 45283. What's your
> > rationale?
>
> I think that was about my earlier attempt to include the actual limit
> in the error message, not the input. I reverted to a generic message,
> because I don't know how to make the test script check for an error
> message that depends on the system/compiler options.
How would the message depend on the system/compiler options?
In any case, you might be able to address this by specifying the
expectations as patterns:
# Each line of a '>' and '?' chunk may be preceded by a '*', so the line
# starts '*>' or '*?'. This signifies that for any line with '*' in front
# the actual output should be pattern matched against the corresponding
# lines in the test output. Each line following '>' or '?' must be a
# valid pattern, so characters special to patterns such as parentheses
# must be quoted with a backslash. The EXTENDED_GLOB option is used for
# all such patterns.
> > > + zlong now;
> > > + zlong end = time_clock_us() + timeout;
> >
> > Could this sum overflow (for example, if the -t option is used)?
>
> I don't think so: timeout is limited to ZLONG_MAX / 2, which
> corresponds to 140000 years or so if zlong is 64-bit. For the sum
> to overflow, the current time as given by either gettimeofday() or
> clock_gettime(CLOCK_MONOTONIC) would have to also be greater than that.
>
Sounds good.
> OTOH, if zlong is only 32-bit, there could be a problem, and in fact my
> function time_clock_us() might not work. However, it was suggested in
> message 45250 that it shouldn't be my problem. Should it be? Should
> this whole patch be disabled somehow on systems that don't support any
> 64-bit type?
I think pws was saying there that failure to detect a 64-bit type _when
one is available_ isn't your problem; i.e., that you can trust configure
to detect a 64-bit type when one is available.
How likely is zsh 5.9 to be ported to a platform that doesn't have a
64-bit type?
If that's a concern, I'd recommend to issue a warning or disable the
feature when we detect that case.
I'm not sure whether that's a concern.
> > > + if (now + timeout_retry > end) {
> >
> > Could this sum overflow (for example, if the -i option is used)?
>
> It might if long and zlong are the same size, as timeout_retry
> is limited to LONG_MAX. The program would then wait past the timeout
> by one interval. But, again, this interval would have to be hundreds
> of thousands of years; if a user requests that, in my opinion, we might
> as well just wait forever.
Thanks, agreed.
> Still, would you like it better if I limited the interval to
> min(LONG_MAX, ZLONG_MAX / 2) instead of LONG_MAX?
Well, it sounds like that won't make any difference to bin_system_flock()'s
behaviour in practice (at least until someone has servers with uptimes
on the order of tens of kiloyears), so I don't have a strong preference.
I suppose I'd recommend whichever of these is more likely to remain
correct even if the code is copied elsewhere and adapted.
Thanks,
Daniel
next prev parent reply other threads:[~2020-03-15 16:55 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 20:35 Cedric Ware
2019-07-29 22:25 ` Bart Schaefer
2020-01-04 18:47 ` Cedric Ware
2020-01-05 18:42 ` dana
2020-01-05 21:49 ` dana
2020-01-06 17:30 ` Cedric Ware
2020-01-06 17:36 ` Peter Stephenson
2020-01-07 3:48 ` dana
2020-01-11 15:41 ` Cedric Ware
2020-01-11 19:36 ` dana
2020-01-12 4:25 ` dana
2020-03-08 18:39 ` Cedric Ware
2020-03-12 18:46 ` dana
2020-03-12 19:13 ` dana
2020-03-14 21:04 ` Cedric Ware
2020-03-15 0:50 ` Daniel Shahaf
2020-03-15 1:04 ` dana
2020-03-15 16:03 ` Cedric Ware
2020-03-15 16:54 ` Daniel Shahaf [this message]
2020-03-15 17:35 ` Peter Stephenson
2020-03-15 18:36 ` Cedric Ware
2020-03-15 19:13 ` Daniel Shahaf
2020-04-13 21:34 ` Cedric Ware
2020-04-14 11:47 ` Daniel Shahaf
2020-04-14 20:21 ` Cedric Ware
2020-04-15 1:15 ` Daniel Shahaf
2020-04-15 2:05 ` dana
2020-04-16 4:24 ` Daniel Shahaf
2020-04-18 16:32 ` Cedric Ware
2020-04-20 17:28 ` dana
2020-04-20 22:17 ` Cedric Ware
2020-03-15 1:04 ` Daniel Shahaf
2020-03-13 14:26 ` dana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200315165410.GA30241@tarpaulin.shahaf.local2 \
--to=d.s@daniel.shahaf.name \
--cc=cedric.ware__bml@normalesup.org \
--cc=dana@dana.is \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).