6 ms·
I wonder if that's been fixed in the OS X/Darwin version of Mach, seems like the only time I ever reboot my MacBook is for system updates.
by jarin 16y ago
I wonder if that's been fixed in the OS X/Darwin version of Mach, seems like the only time I ever reboot my MacBook is for system updates.
- zackb 16y agoI wonder if there's an update for my MkLinux box! http://mklinux.org/ http://mklinux.org/
- mikeryan 16y agoThis: the only time I ever reboot my MacBook is for system updates Seems to indicate that it has ;-)
- eibrahim 16y agoreally man? maybe you are not using your macbook long enough or you are simply browsing the internet with it? I reboot my macbook pro (running leopard) as often as I reboot my windows 7 PC which is not much. Except I use the Win7 machine 90% of the time and for much more "intensive" stuff.
- blago 16y agoAs a fellow mac user: If you are rebooting your Mac for reasons other then system upgrade, something is wrong with your machine. I say this as someone who compiles from source and runs server software on my mac almost every day. mogodb, apache, nodejs, mysql, tomcat is just the tip of the iceberg in the server department.
- technomancy 16y ago> If you are rebooting your Mac for reasons other then system upgrade, something is wrong with your machine Indeed; that is the point of the article. =)
- larsberg 16y agoOr you have made the grave, grave mistake of installing Adobe products on your machine.
- Derbasti 16y agoExcept for those who rely on Boot Camp for gaming. These people have to reboot whenever they want to switch from work mode to game mode.
- JoeAltmaier 16y agoMaybe app users experience this. I use a Mac Mini for development/test as an alternate platform. I have to reboot the dang thing every day or two. The development tools hang and screw up. The network drops and needs to be unplugged/plugged back in or rebooted. The debugger totally fails to breakpoint and only a reboot will fix it. I alternate between banging my head on the wall, and white-hot fury at the thing. Fortunately I only occasionally have to verify the code still runs there, and don't have to live in that environment.
- jarin 16y agoI use it probably 14+ hours a day, and it's variously running MySQL, Redis, MongoDB, Photoshop, 600 million Chrome tabs, Xcode and Starcraft 2 whenever possible :) I did experience memory leaks with pretty much every Bittorrent client, but I haven't torrented any uh, Linux distros in forever.
- reneherse 16y agoJust asking, but how do you keep so many Chrome tabs open without things getting sluggish? My MBP (2008 pre-unibody/Leopard) seems to get bogged down with just a couple score of Chrome tabs. Granted, I don't know much about what's going on under the hood (I'm a designer, not a programmer) but Activity Monitor shows that each tab uses a gig of virtual memory...
- foljs 16y ago> Just asking, but how do you keep so many Chrome tabs open without things getting sluggish? My MBP (2008 pre-unibody/Leopard) seems to get bogged down with just a couple score of Chrome tabs. Avoid Flash. Install something like ClickToFlash, FlashBlock etc. I have tens of tabs open no problem. (Then again, I'm on a Quat iMac)
- tjarratt 16y agoJust a guess, I think there might be some APIs available in SnowLeopard that allow Chrome to write its tabbed content to files and read it in asynchronously more easily than they could have in Leopard. Sometimes when I switch to a tab that has been idle for over a hour, I notice it takes chrome some time to render it again. Also, most developers tend to buy machines with the maximum RAM they can. I've got 4GB in my macbook pro and the 20 chrome tabs can't be taking up more than 500MB all together. Comparatively, Safari seems to take up a lot more memory than Chrome.
- seabee 16y ago> Sometimes when I switch to a tab that has been idle for over a hour, I notice it takes chrome some time to render it again. That sounds like paging in effect, which is decades old. Maybe you just notice it more now!
- CountSessine 16y agoThe original poster in that thread was running 10.5.8. No one in the thread posted saying that they couldn't repro the port leak. The thread is quite recent, the latest post being from earlier today. I think we have to assume that the port leak is still there in the most recent version (10.6.6). I do hope that the poster had misunderstood Avie Tevanian in his conversations with him. Tevanian was one of Apple's chief architects and was one of the big wheels responsible for NextStep's transformation to OS X. It would be kind of outrageous for an OS architect to believe that it's at all acceptable to allow user-mode processes to cause kernel resource leaks.
- jrockway 16y agoIt was an engineering trade-off like any other. Would you be willing to reboot your computer once a month if it meant everything would be 1000x faster? Of course. So were the Mach designers, apparently.
- jwatzman 16y agoWhile the discussion in that thread may or may not apply to OS X, be very careful when saying "X is true about Mach therefore X is probably true about Darwin". A friend of mine put it very well: OS X was Mach once in the same way that orcs were elves once.
- eschaton 16y agoYou're misinterpreting the post; Mikel wasn't talking about the same leak the original thread was. He was just talking about how he fixed a leak many years ago. Using Mach ports correctly without leaking is hard, similarly to how using C's malloc/free without leaking is hard. The former no more implies a current flaw in Mach than the latter implies a current flaw in C stdlib.
- klodolph 16y agoKernels should not have resource leaks. A web server that leaks memory implies nothing wrong with the clients, a kernel that leaks memory implies nothing wrong with the user space programs. It just means that there are cases that the kernel developers didn't think of, just like the people who made Apache didn't think of the Slowloris attack. Heck, a few months ago someone exhausted Linux kernel fds in just by shuffling socket pairs around (just 40 lines of C with three syscalls). These are problems, ranging from remote DOS attacks, local DOS attacks, to accidental DOS attacks.