3 ms·

The browser doesn't have to know or care if some javascript on a page is doing an infinite loop. It's quite possible to sandbox a tab so that it can't take down

by rand_r 14y ago

The browser doesn't have to know or care if some javascript on a page is doing an infinite loop. It's quite possible to sandbox a tab so that it can't take down the browser, just like an OS sandboxes processes so that one can't take down the kernel and other processes just from using too much CPU.

jiggy2011 14y ago
That is true in that Chrome always seems handle this better than Firefox for example. I guess it is to do with scheduling the browser UI threads and the JS threads. Although perhaps there are issues with locks and contention because there is probably some shared state between the browser UI thread and the JS engine/DOM on that tab. Thing is once you start implementing stuff inside the browser to handle these situations your browser is moving away from being a document reader program and into the realms of being a full blown OS in it's own right running on top of another OS with shared state between the two. That adds a load of complexity on it's own.
- pmjordan 14y ago
  Even without a true sandbox, and with JITed/compiled code, you should be able to run it on a stack of its own, either a distinct kernel thread or a user space thread. If the code doesn't call out to event-handling code frequently enough, a watchdog thread can send it a signal; the signal handler may then choose to cause the thread to pause execution or reschedule or whatever. It's not exactly simple, but also not that outlandishly difficult compared to creating the JIT compiler in the first place! Of course, it depends if you're merely having to avoid blocking the UI thread or if you're also interested in preventing runaway CPU usage. Browsers stopped being document readers well over a decade ago, even if they seem like one to the user.
  - jiggy2011 14y ago
    I don't think it's so much technical difficulty as much as it is that you are dealing with metrics that are hard to pin down. For example, how frequently should the UI code be called out to? I guess that would depend on the speed of the computer it is running on. If it's a very slow computer then stuff is just going to be slow whatever you do , doesn't mean it's crashed. Otherwise you'd end up with a situation where you have to say "sorry , your computer doesn't meet the minimum requirements to view this webpage". Also expectations are going to differ depending on the use case. For example if I load up a huge 1GB spreadsheet I can live with the fact that the spreadsheet program is going to be unusable for a minute or two while it loads the data. On the other hand if I click on a link and the page on the other end has a buggy flash applet or whatever then having my browser suddenly lock up is way more frustrating. I suppose part of this stems from the fact that sometimes a browser is a document reader and sometimes it's an application runtime but there's no way to tell which it should be for a particular page. You could add a header or something but that would just get horribly abused.

by rand_r 14y ago

jiggy2011 14y ago

That is true in that Chrome always seems handle this better than Firefox for example. I guess it is to do with scheduling the browser UI threads and the JS threads. Although perhaps there are issues with locks and contention because there is probably some shared state between the browser UI thread and the JS engine/DOM on that tab. Thing is once you start implementing stuff inside the browser to handle these situations your browser is moving away from being a document reader program and into the realms of being a full blown OS in it's own right running on top of another OS with shared state between the two. That adds a load of complexity on it's own.

pmjordan 14y ago
Even without a true sandbox, and with JITed/compiled code, you should be able to run it on a stack of its own, either a distinct kernel thread or a user space thread. If the code doesn't call out to event-handling code frequently enough, a watchdog thread can send it a signal; the signal handler may then choose to cause the thread to pause execution or reschedule or whatever. It's not exactly simple, but also not that outlandishly difficult compared to creating the JIT compiler in the first place! Of course, it depends if you're merely having to avoid blocking the UI thread or if you're also interested in preventing runaway CPU usage. Browsers stopped being document readers well over a decade ago, even if they seem like one to the user.
- jiggy2011 14y ago
  I don't think it's so much technical difficulty as much as it is that you are dealing with metrics that are hard to pin down. For example, how frequently should the UI code be called out to? I guess that would depend on the speed of the computer it is running on. If it's a very slow computer then stuff is just going to be slow whatever you do , doesn't mean it's crashed. Otherwise you'd end up with a situation where you have to say "sorry , your computer doesn't meet the minimum requirements to view this webpage". Also expectations are going to differ depending on the use case. For example if I load up a huge 1GB spreadsheet I can live with the fact that the spreadsheet program is going to be unusable for a minute or two while it loads the data. On the other hand if I click on a link and the page on the other end has a buggy flash applet or whatever then having my browser suddenly lock up is way more frustrating. I suppose part of this stems from the fact that sometimes a browser is a document reader and sometimes it's an application runtime but there's no way to tell which it should be for a particular page. You could add a header or something but that would just get horribly abused.