Archive of UserLand's first discussion group, started October 5, 1998.

startup.startupScript revision

Author:Dave Winer
Posted:8/19/1999; 6:30:12 AM
Topic:startup.startupScript revision
Msg #:9658
Prev/Next:9657 / 9659

I had the misfortune of installing a virgin Frontier 6.0 on a nearby machine, a slow one. Everything went fine at first, but then about 18 seconds after launching the app CPU Utilization went to 100 percent and stayed there. I quit and relaunched. Same thing! I gave up.

Then I posted an internal message and Andre said he had seen the same thing and had traced it to a weird thing that scheduler.monitor has been doing for at least a few months, probably longer. When it reschedules a task it loops over the task's taskTime database entry, incrementing it until it's in the future. Usually it loops once. But if it's been a long time since you ran Frontier, well, it takes a long long time! Enough so you can perceive it and be frustrated by it and think that the app is broken.

Why does this show up in a virgin install? Because it thinks it's April 1999! This wasn't such a big deal in May. It became worse in June, and noticable in July, and it's a deal-stopper in August. It's a bug that gets worse over time!

Oy! So we looked into how to fix it and this is what we came up with. On startup, startup.startupScript will set up the taskTimes so they make sense. We avoid the problem with scheduler.monitor by doing a rational initialization.

The code

The new code appears in system.startupScript, immediately after the call to scheduler.init.

http://pointers.userland.com/startupscript

Breakage?

I'm posting this because I want to know if this will break anyone.

Also, since we're going to do a rev of startup.startupScript, are there any other feature requests for Frontier 6.1 as it starts up? This script is open right now, it's a good time to take a look.



There are responses to this message:

This page was archived on 6/13/2001; 4:51:58 PM.

© Copyright 1998-2001 UserLand Software, Inc.