• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Five Reasons Why Synchronous Networking Is Bad
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Five Reasons Why Synchronous Networking Is Bad


  • Subject: Re: Five Reasons Why Synchronous Networking Is Bad
  • From: email@hidden
  • Date: Fri, 06 Mar 2009 09:02:33 -0700

On Mar 6, 2009, at 3:39 AM, email@hidden wrote:

Wow, that's very strange. I don't think that's at all typical. You did upgrade your computer to more than 256MB of RAM, right? ;-)

Geez Jens, at least he doesn't attach a signature file to every email

" ;-) "

No need for smarty comments on a professional mailing list, surely, thanks

Hahaha. I'm just saying, every browser I've ever used, on any computer, no matter how powerful, beachballs at some point. Maybe it is all due to Flash, in fact that makes sense because it might be handled on the main thread, and flash probably isn't sleeping often enough to give control back to the browser. I do notice that the stalling almost always happens while loading ads, and ads are almost always Flash. What a coincidence. I have this workflow I go through where when the browser stalls, I check my email or do something else for a minute until it comes back, and no other apps are beachballing, so I guess that rules out virtual memory thrashing. But in a way, that demonstrates how powerful a browser would be if everything in each tab, including plugins, was running in its own process, or at the very least a sandboxed thread of some sort that can't stall the main thread.


That gets me thinking now, that maybe what we really need are sandboxed plugins. For example, a plugin that runs flash on a separate thread, so that the browser never has to wait on it. Unfortunately though, it's very difficult to write loops around things like the javascript interpreter, because often the parent process is waiting on an answer from the script. In fact it might be nontrivial to the point of impossible to make "nonblocking" plugins that have to be babysat round robin. So maybe for security, Safari should do what Chrome is doing and make a rule that plugins and scripts can never be called from the main thread, period. Another nice benefit of sealing off the tabs is that they could better take advantage of multiple cores. Maybe there is still time to make that WebKit browser after all hah. OK I'm done pestering the group about this topic.

--Zack

P.S:

"We are all failures -- at least, all the best of us are."
--Sir James M. Barrie, British Playwright
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Five Reasons Why Synchronous Networking Is Bad
      • From: Josh Graessley <email@hidden>
References: 
 >Five Reasons Why Synchronous Networking Is Bad (From: Quinn <email@hidden>)
 >Re: Five Reasons Why Synchronous Networking Is Bad (From: Peter Sichel <email@hidden>)
 >Re: Five Reasons Why Synchronous Networking Is Bad (From: email@hidden)
 >Re: Five Reasons Why Synchronous Networking Is Bad (From: Jens Alfke <email@hidden>)
 >Re: Five Reasons Why Synchronous Networking Is Bad (From: email@hidden)
 >Re: Five Reasons Why Synchronous Networking Is Bad (From: Joel Reymont <email@hidden>)
 >Re: Five Reasons Why Synchronous Networking Is Bad (From: email@hidden)

  • Prev by Date: Re: Five Reasons Why Synchronous Networking Is Bad
  • Next by Date: Re: Five Reasons Why Synchronous Networking Is Bad
  • Previous by thread: Re: Five Reasons Why Synchronous Networking Is Bad
  • Next by thread: Re: Five Reasons Why Synchronous Networking Is Bad
  • Index(es):
    • Date
    • Thread