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,
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. Some
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
"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 nam
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
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() t
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
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 fin
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 exp
On Tue, Jan 30, 2001 at 02:09:32PM -0200, Branden wrote:
> 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()
David Mitchell wrote:
> Sorry, I misunderstood you. I think in fact we agree! What I was
> advocating was that Perl should automatically make accesses to
> individual shared variables safe, so 2 threads executing
> 1: $shared = 10; 2: $shared = 20;
>
> wont guarantee whether $shared ends up as 1
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 th
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 c
"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 misu
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;
> >
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
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);
> }
>
"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. Eve
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 can
19 matches
Mail list logo
