[whatwg] Active workers when user leaves the page
This is something that have been in the back of my brain for a few days: How do we deal with the user navigating a way from a page if there's a Worker in the middle of some very long running script? First off, please notice that this discussion is 100% orthogonal to the communications API discussion that is ongoing in another thread. I don't want to get the two mixed up. We don't really want to always allow a worker to finish working, even if the user leaves the only page that is currently using the worker. I.e. if someone has an infinite loop (by accident or intentionally), I don't think we want to leave that running until the user shuts down the browser. In fact, the user could very well be leaving the page because he/she feels that it is sucking up too much CPU power. One possible solution is to simply set the .closing flag inside the worker and hope that the worker will honor that flag and break out ASAP. The UA could even at that point give the worker some set amount of time before forcefully killing the worker. We have a concept of a 'slow script' dialog in firefox that we use if scripts on the main thread take too long to run. The dialog asks the user if he/she wants to continue running the current script, or forcefully break it. This will not usually be used for workers (the whole point is that they take a long time to finish), but we could engage it once the user tries to leave the page. I do want to be agressive with killing workers when the user leaves a page since that makes for better user experience. However I'm also worried about stopping scripts halfway through breaking things and leaving the site with half-finished operations that are stored in databases or localStorage. Also note that the the presence, or lack of, fastback cache doesn't really make a difference. Pages are eventually going to get purged from the fastback cache, so it just pushes the problem to a point a little later in time. How has gears dealt with this problem so far? What are your experiences with it? / Jonas
Re: [whatwg] Active workers when user leaves the page
On Fri, 8 Aug 2008, Jonas Sicking wrote: This is something that have been in the back of my brain for a few days: How do we deal with the user navigating a way from a page if there's a Worker in the middle of some very long running script? Right now the spec says that closing becomes true, and if the worker doesn't clean up promptly, the kill a worker algorithm is invoked and the script is killed, the unload handler is handled, and the script is killed again if that doesn't end prompty either. Also note that the the presence, or lack of, fastback cache doesn't really make a difference. Pages are eventually going to get purged from the fastback cache, so it just pushes the problem to a point a little later in time. Yup, the spec deals with this already too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Active workers when user leaves the page
On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking [EMAIL PROTECTED] wrote: I do want to be agressive with killing workers when the user leaves a page since that makes for better user experience. However I'm also worried about stopping scripts halfway through breaking things and leaving the site with half-finished operations that are stored in databases or localStorage. Aggressive killing of workers without warning when the user navigates away would actually be a good feature. There are various reasons outside anyone's control that a worker might die abruptly. For example, power failure, browser crash, or slow-script style timeout. Applications need to be able to handle those cases, for example by using database transactions or careful use of atomic operations. But that's hard to test and authors probably won't design or test well for those cases since they're relatively uncommon. Expanding abrupt termination scenarios to include navigate-away makes abrupt termination much easier to test, forces authors to design for it early, and will ultimately simplify the application design by reducing the different ways a worker can terminate. This may sound a bit radical, but it's not a new idea. It's a principle sometimes called crash-only software. See e.g. http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/ Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Active workers when user leaves the page
Hi, Could it not be set that a there is a maximum execution time for any workers that are still active, definable by the browser but with a suggested value of say 1000milliseconds in the spec, any processing that takes longer than this is killed, but gives the option for well built scripts and cleanup processes to run gracefully. Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert O'Callahan Sent: 08 August 2008 23:30 To: Jonas Sicking Cc: whatwg Subject: Re: [whatwg] Active workers when user leaves the page On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking [EMAIL PROTECTED] wrote: I do want to be agressive with killing workers when the user leaves a page since that makes for better user experience. However I'm also worried about stopping scripts halfway through breaking things and leaving the site with half-finished operations that are stored in databases or localStorage. Aggressive killing of workers without warning when the user navigates away would actually be a good feature. There are various reasons outside anyone's control that a worker might die abruptly. For example, power failure, browser crash, or slow-script style timeout. Applications need to be able to handle those cases, for example by using database transactions or careful use of atomic operations. But that's hard to test and authors probably won't design or test well for those cases since they're relatively uncommon. Expanding abrupt termination scenarios to include navigate-away makes abrupt termination much easier to test, forces authors to design for it early, and will ultimately simplify the application design by reducing the different ways a worker can terminate. This may sound a bit radical, but it's not a new idea. It's a principle sometimes called crash-only software. See e.g. http://www.usenix.org/events/hotos03/tech/full_papers/candea/candea_html/ Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- This message has been scanned for viruses and dangerous content by MailScanner http://www.mailscanner.info/ , and is believed to be clean.
