From: Adam R. M. <ama...@ma...> - 2007-07-07 21:24:37
|
On Jul 7, 2007, at 14:11, Christiaan Hofman wrote: > > > On 7/7/07, Christiaan Hofman <cmh...@gm...> wrote: > On 7 Jul 2007, at 10:33 PM, Adam R. Maxwell wrote: > > > > > On Jul 7, 2007, at 13:18, Christiaan Hofman wrote: > > > >> I'm completely lost why sometimes we don't get kqueue change > >> notifications. It happens consistently when opening a file using > >> our - > >> handleOpenScriptCommand: override in SKApplciation. That is, when > >> opening using AppleScript with a tex line argument. It just opens > the > >> document using -openDocumentWithContentsOfURL:display:error:, which > >> should b sufficient. I checked that the document does register with > >> UKKqueue. > > > > Does it register the correct path, and not some weird temporary file > > (or nil)? I don't recall the code path for that anymore. I'd log > all > > calls to UKKqueue to see what's added or removed (my setup is sort > of > > hosed right now, so I haven't tried it). > > > > -- adam > > I think I found the problem. It's something I was unsure about > earlier but forgot about. The notifications are registered for the > file path as the object. That's wrong, as the object is compared > using pointer equality, /not/ isEqual. Yeah, I forgot about that implementation detail (which Apple ought to document). How about just registering for nil and comparing the path from the notification's userInfo? > I'm not sure how to fix this > though, as the fileName of the document can change when the file is > moved or deleted, while we should still observe those changes. Also > UKKqueue does not ensure that it always uses the same instance for > the notification name, so it's also wrong. UKKqueue always uses the original file path pointer for the notification, as passed in. > Is it much of an overhead to have one UKKqueue for each document? Not really. It does create another thread, but there's very little memory overhead AFAIK. -- adam |