Mumpster
http://mumpster.org/

Possible New Proposal: Portable Hang and Timeout Precision
http://mumpster.org/viewtopic.php?f=20&t=1766
Page 1 of 2

Author:  toad [ Sat Feb 01, 2014 3:36 pm ]
Post subject:  Possible New Proposal: Portable Hang and Timeout Precision

Mostly, we are not adding new proposals for MUMPS 2015. Instead, mostly we're carefully selecting a noncontroversial subset of the MDC Type A Extensions the MDC already approved, postponing the invasive ones, but focusing on bug fixes, promised or inevitable extensions, and portability improvements.

But we are finding a small number of bug fixes and portability improvements that we need, for which new MDC Type A Extension exists yet. For these, and only these, we're going to go ahead and develop new proposals and run them through the exacting MDC proposal process to create some new Type As.

I posted one idea earlier today, to remove the ambiguity in the definition of SET $X and SET $Y. This one is about upgrading MUMPS's portability.

Since time immemorial, the Hang command has only supported whole-second precision. Here's the text from clause 8.2.8 HANG:

Quote:
Let t be the value of numexpr. If t '> 0, HANG has no effect. Otherwise, execution is suspended for t seconds.


This is clarified in Section 2 of the standard, where the portability limits are applied:

Quote:
12 OTHER PORTABILITY REQUIREMENTS

Programmers should exercise caution in the use of noninteger values for the HANG command and in timeouts. In general, the period of actual time which elapses upon the execution of a HANG command cannot be expected to be exact. In particular, relying upon noninteger values in these situations can lead to unexpected results.


Together, these two clauses mean that although you can use non integer arguments to Hang, the results are unpredictable and therefore vendor-specific, unportable. This keeps us limited to integers, that is, to whole seconds of precision.

That is not very precise.

There is a related subject in the precision of timeouts. Times outs are defined in clause 8.1.5 Command timeout timeout:

Quote:
The OPEN, LOCK, JOB, and READ commands employ an optional timeout specification, associated with the testing of an external condition.

Code:
[u]timeout[/u] ::=  : [u]numexpr[/u]


If the optional timeout is absent, the command will proceed if the condition, associated with the definition of the command, is satisfied; otherwise, it will wait until the condition is satisfied and then proceed.
                        
$TEST will not be altered if the timeout is absent.


If the optional timeout is present, the value of numexpr must be nonnegative. If it is negative, the value 0 is used. Numexpr denotes a t-second timeout, where t is the value of numexpr.


If t = 0, the condition is tested. If it is true, $TEST is set to 1; otherwise, $TEST is set to 0. Execution proceeds without delay.

If t is positive, execution is suspended until the condition is true, but in any case no longer than t seconds. If, at the time of resumption of execution, the condition is true, $TEST is set to 1; otherwise, $TEST is set to 0.


And, of course, as quoted above, clause 12 of section 2 limits portable timeouts to whole seconds, just like it does Hang arguments.

For a modern programming language, we can do better. Most implementations of MUMPS are written in C, and there are C calls available to support sub-second precision in Hangs. On Linux, usleep(3) will support microsecond Hangs. On Windows, Sleep() will support milliseconds. So for a portable MUMPS, it sounds like millisecond is our maximum precision. I'd love info on other major operating systems MUMPS runs on, so we can feel out the implementation impact of this possible new proposal.

I would like to collect data on how precise current MUMPS implementations are, and how easy or hard it would be to settle on a new subsecond standard for Hangs.

Since timeouts are handled by a different mechanism, I'd like to separately gather that same info about timeouts.

Once we see where everyone is today, we can settle on what we'd like to propose for MUMPS 2015.

(Thanks to David Wicksell for raising this topic, talking it through with me, and finding the C calls.)

Author:  toad [ Sat Feb 01, 2014 3:38 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

Here's the link to Windows Sleep: http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Here's the link to Unis usleep(3): http://man7.org/linux/man-pages/man3/usleep.3.html

Again, thanks to David Wicksell, for sharing the links.

Author:  gwoodhouse [ Sat Feb 01, 2014 5:40 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

OS X will accept a non-integer number of seconds as an argument to sleep, but strongly emphasizes that this is non-portable. I can see accepting non-integer arguments to HANG so long as the standard makes no guarantees regarding intervals that are not an integral number of seconds. From a different point of view, I'm not convinced it is good practice to rely on sub second sleep or HANG arguments. Can anyone offer a good use case here?

Author:  toad [ Sat Feb 01, 2014 7:34 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

So you are saying that although Linux can hang for microseconds, the Unix underneath Mac OS X cannot? Does that mean the C usleep(3) call is not available under OS X?

I hope that is not true. Perhaps some implementors could help us out.

Author:  raynewman [ Sat Feb 01, 2014 10:07 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

OSX supports usleep - the runtime environment is after all just FreeBSD.

Ray

Author:  toad [ Sat Feb 01, 2014 10:12 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

Ray, whew!

So Windows, Linux, and OS X should all support millisecond precision.

Author:  gwoodhouse [ Sun Feb 02, 2014 12:50 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

I didn't say it didn't support millisecond precision, only that there is a portability warning. What does POSIX say here?

Author:  toad [ Sun Feb 02, 2014 12:55 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

Greg, that is an excellent question.

Would someone like to check out for us what POSIX says about using sub-second precision for sleep?

Author:  dlw [ Sun Feb 02, 2014 4:46 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

A further thing to consider is that usleep(3) is obsolete. It will still work, but it is suggested that nanosleep(2) be used instead. Here is the relevant portion of the man page:

Quote:
4.3BSD, POSIX.1-2001. POSIX.1-2001 declares this function obsolete;
use nanosleep(2) instead. POSIX.1-2008 removes the specification of
usleep().


It has several advantages over usleep(3) as well, including a guarantee that it won't be implemented with signals, meaning that it won't cause issues with other calls that are, like sleep(3) or alarm(2).

I believe it should still work with FreeBSD, and therefore Mac OSX; but even if it doesn't, Ray Newman has indicated that usleep(3) does.

Anyway, just a suggestion that we consider using nanosleep(2) in Linux implementations.

Author:  toad [ Sun Feb 02, 2014 6:02 pm ]
Post subject:  Re: Possible New Proposal: Portable Hang and Timeout Precisi

So that confirms Greg's suggestion that we not use usleep(3). If POSIX likes nano sleep(2), then I like it too.

Page 1 of 2 All times are UTC - 8 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/