July 2012 - Darwin-dev - lists.apple.com

Re: Can't re-open serial port after closing it
by Tilghman Lesher 14 Jul '12

14 Jul '12

On Fri, Jul 13, 2012 at 9:26 PM, Rick Mann <rmann(a)latencyzero.com> wrote: > One last thing I don't understand: I set the FD to TIOCEXCL, which my comment says will disallow multiple opens, and which my own code experiences (it comes back as busy), but which -readInBackgroundAndNotify doesn't seem to have a problem with. It's probably using dup2() on the file descriptor. -Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Can't re-open serial port after closing it
by Rick Mann 14 Jul '12

14 Jul '12

On Jul 13, 2012, at 18:37 , Tilghman Lesher wrote: > On Fri, Jul 13, 2012 at 8:32 PM, Rick Mann <rmann(a)latencyzero.com> wrote: >> Nope. Straight-up Cocoa app. I did some checking to make sure NSFileHandle was indeed closing the file descriptor, and it is. I tried closing it for it with close(), but it made no difference. > > If you have lsof on your system, it's worth a try to see what else has > it open. You might be surprised. Fascinating. I open the device twice. Once when I expressly open it using POSIX, and again later, as a result of calling -readInBackgroundAndNotify on the NSFileHandle. I'm having trouble understanding the docs. They say: "If you want to use a file handle object with a file descriptor that you created, use the initWithFileDescriptor: method…" Which is what I use. But calling close on that closes the first FD, the one I opened, and leaves the second one open. If the notification gets posted, the FD is closed. It's re-opened each time -readInBackgroundAndNotify is called, and left open on closeFile. I suspect it gets closed in NSFileHandle's -dealloc, but since I'm running in ARC, and I'm not nilling out my reference to the NSFileHandle, it never gets disposed. I then go to try to open the file again, and it fails. It's not until after that that I create a new NSFileHandle and thus free the old one. One last thing I don't understand: I set the FD to TIOCEXCL, which my comment says will disallow multiple opens, and which my own code experiences (it comes back as busy), but which -readInBackgroundAndNotify doesn't seem to have a problem with. Thanks, Tilghman, for the lsof suggestion. -- Rick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Can't re-open serial port after closing it
by Tilghman Lesher 14 Jul '12

14 Jul '12

On Fri, Jul 13, 2012 at 8:32 PM, Rick Mann <rmann(a)latencyzero.com> wrote: > Nope. Straight-up Cocoa app. I did some checking to make sure NSFileHandle was indeed closing the file descriptor, and it is. I tried closing it for it with close(), but it made no difference. If you have lsof on your system, it's worth a try to see what else has it open. You might be surprised. -Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Can't re-open serial port after closing it
by Rick Mann 14 Jul '12

14 Jul '12

Nope. Straight-up Cocoa app. I did some checking to make sure NSFileHandle was indeed closing the file descriptor, and it is. I tried closing it for it with close(), but it made no difference. On Jul 13, 2012, at 18:31 , Chris Suter wrote: > Hi Rick, > > On Saturday, 14 July 2012, Rick Mann wrote: > I've got some code that opens a serial port, uses it, and then closes it (by calling close on the file descriptor). If I try to re-open it, I get a "resource busy" error. If I quit my app and try again, it's fine. > > Any ideas? > > Does your program spawn any child processes? If it does, you need to take care that the file descriptor is closed in the child process. There are a number of ways of doing that. > > Kind regards, > > Chris _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Can't re-open serial port after closing it
by Chris Suter 14 Jul '12

14 Jul '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Can't re-open serial port after closing it
by Rick Mann 14 Jul '12

14 Jul '12

I've got some code that opens a serial port, uses it, and then closes it (by calling close on the file descriptor). If I try to re-open it, I get a "resource busy" error. If I quit my app and try again, it's fine. Any ideas? Thanks, Rick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: WrMeta
by Dave Keck 09 Jul '12

09 Jul '12

Thanks for your help Chris & Tilghman -- with your insight I'm seeing 25-35% speedups in my app. Here's an example code snippet to help those in the future; it disables access-time updates for the current thread: #include <sys/types.h> #include <sys/sysctl.h> int sysctlValue = KERN_RAGE_THREAD; int sysctlResult = sysctlbyname("kern.rage_vnode", NULL, NULL, &sysctlValue, sizeof(sysctlValue)); assert(!sysctlResult); _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: WrMeta
by Tilghman Lesher 09 Jul '12

09 Jul '12

On Sun, Jul 8, 2012 at 9:03 PM, Chris Suter <chris(a)sutes.me> wrote: > Hi, > > On Sun, Jul 8, 2012 at 6:14 AM, Tilghman Lesher <tilghman(a)meg.abyt.es> > wrote: >> >> On Fri, Jul 6, 2012 at 5:10 PM, Dave Keck <davekeck(a)gmail.com> wrote: >> >> Since this should be asynchronous, I'd be surprised if this is causing >> >> a significant performance degradation... >> > >> > Thanks Shantonu! -- it was indeed updating the access time. >> > >> > Is there a supported way to prevent my process from updating the >> > access time? My initial benchmarks show a 28% performance increase in >> > processing 4000 photos (82 seconds before, 64 seconds after). >> >> Not your process, but you can at the filesystem mount level: >> http://oroyphoto.com/2010/11/12/mac-os-x-noatime-settings-for-10-6/ > > > According to the Kernel sources, there’s something called “rapid aging” that > might be relevant. Documentation is sparse so I don’t know its intended use, > but it looks like something you can set per-process that will prevent access > times from being set. Per process or per thread, apparently. The usage is to call sysctl(3) with KERN_RAGEVNODE and one of 4 magic values: /* KERN_RAGEVNODE types */ #define KERN_RAGE_PROC 1 #define KERN_RAGE_THREAD 2 #define KERN_UNRAGE_PROC 3 #define KERN_UNRAGE_THREAD 4 The IOS documentation suggests that it's to be used only by background tasks which request rapid aging, but other than that, I can find no mention of the recommended way to ask for rapid aging. Comments in the kernel also suggest that when an open vnode is accessed by a "normal" process, rapid aging is turned off. -Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: WrMeta
by Chris Suter 09 Jul '12

09 Jul '12

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0

Re: WrMeta
by Tilghman Lesher 07 Jul '12

07 Jul '12

On Fri, Jul 6, 2012 at 5:10 PM, Dave Keck <davekeck(a)gmail.com> wrote: >> Since this should be asynchronous, I'd be surprised if this is causing a significant performance degradation... > > Thanks Shantonu! -- it was indeed updating the access time. > > Is there a supported way to prevent my process from updating the > access time? My initial benchmarks show a 28% performance increase in > processing 4000 photos (82 seconds before, 64 seconds after). Not your process, but you can at the filesystem mount level: http://oroyphoto.com/2010/11/12/mac-os-x-noatime-settings-for-10-6/ -Tilghman _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.ap… This email sent to site_archiver(a)lists.apple.com

1 0