Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
sleep($time);
}
else {
select(undef, undef, undef, $time);
}
}
Why
"Branden" [EMAIL PROTECTED] wrote:
Well, mandatory locking is something we should definetly NOT have in Perl6.
Most of perl's code today is not threaded, and I believe much of it will
continue to be this way. The pseudo-fork thread behaviour that is being
proposed also makes this ok. Even if
On Tue, Jan 30, 2001 at 04:13:39AM -0500, Michael G Schwern wrote:
Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
sleep($time);
}
David Mitchell wrote:
I let the Perl developers do all
the hard locking code behind the scenes, and I don't have to worry my
pretty
little head about it.
Now, there may be practical reasons why it isnt possible for perl to do
this for me automatically (reasons, anyone?), but it's a nice
At 09:43 AM 1/30/2001 -0600, Jarkko Hietaniemi wrote:
On Tue, Jan 30, 2001 at 04:13:39AM -0500, Michael G Schwern wrote:
Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
sub sleep {
my($time) = shift;
if(
"Branden" [EMAIL PROTECTED] wrote:
The thing with mandatory locks per variable, is that as long as you only
want to access _that_ variable, it's ok, but if you want to make several
uses of several variables and want to do it all at once, you've got a
problem.
[ big snip ]
Sorry, I
Jarkko Hietaniemi wrote:
I guess it's part of the can of sub-second worms: if we do sleep(),
people will ask why don't we do time() and alarm(), too. sleep() and
alarm() we could get away with more easily, but changing time() to do
subsecond granularity would be A Bad Thing for backward
On Tue, Jan 30, 2001 at 10:49:56AM -0500, Dan Sugalski wrote:
At 09:43 AM 1/30/2001 -0600, Jarkko Hietaniemi wrote:
On Tue, Jan 30, 2001 at 04:13:39AM -0500, Michael G Schwern wrote:
Is there any really good reason why sleep() doesn't work for
microseconds? I mean, if I can do this:
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something crashing and burning because some other place expects
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something crashing and burning because some other place expects
to find a
On Tue, 30 Jan 2001, Nathan Wiger wrote:
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something
Lightning flashed, thunder crashed and Jarkko Hietaniemi [EMAIL PROTECTED] whispered
:
| I guess it's part of the can of sub-second worms: if we do sleep(),
| people will ask why don't we do time() and alarm(), too. sleep() and
| alarm() we could get away with more easily, but changing time() to
On Tue, Jan 30, 2001 at 05:49:43PM -0200, Branden wrote:
Well, then I propose the same of RFC 48: deprecate time() and create another
name to refer to the number of seconds since (an epoch) with decimals for
fractions of seconds. Maybe it could be called now() or timestamp(). Then
time
"Stephen P. Potter" wrote:
Why do we have to worry about changing time()? There's a real parallel
between sleep() and alarm(), so we would want to do both if we did either,
but time() really has no relation to them.
Or, should we just implement usleep() and (for lack of a better name)
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
But the big problem is that there's a lot of stuff that's based off of
time() right now, like stat(), lstat(), etc, etc. When you think of the
cascading effects of changing Perl's timekeeping it gets really, really
sticky.
I
On Tue, Jan 30, 2001 at 01:07:18PM -0800, Nathan Wiger wrote:
If the internal timekeeping were changed, one thing that's apparent from
the discussions is that there would *have* to be a core way of providing
exactly what time() does currently or lots of stuff would break really
badly. Someone
Lightning flashed, thunder crashed and Nathan Wiger [EMAIL PROTECTED] whisper
ed:
| But the big problem is that there's a lot of stuff that's based off of
| time() right now, like stat(), lstat(), etc, etc. When you think of the
| cascading effects of changing Perl's timekeeping it gets really,
17 matches
Mail list logo
