Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kqueue on OS X

On Feb 17, 2004, at 7:01 PM, Glen Low wrote:
> My issue is simply this: I will run kqueue and kevent in a separate
> thread, as you have done. However I need to break into the kevent
> thread from my main event loop from time to time, to update the list
> of files to watch, e.g. when the file is closed from the GUI. This
> implies I need to send the kqueue some kind of event it recognizes.
> Now pipes and file descriptors seem dangerous to me, since they are
> not necessarily threadsafe (especially with Cocoa), and UNIX signal
> seems like overkill -- however if the kqueue could monitor a Mach
> port, well the main thread could interrupt it by sending it a Mach
> message.
>
> That led me to look at sys/event.h, and discovering there
> EVFILT_MACHPORT and EVFILT_FS. Presumably for EVFILT_MACHPORT, the
> kqueue ident is a Mach port identifier? What kind of data could I
> expect, etc.?

Closing a file in one thread, while another is watching for events from
that file, is safe (as far as the mechanism itself is concerned -
closing the ffd automatically and atomically removes the events
associated with that fd from all kqueues in the process). However, if
you recycle that fd while an event was still in the process of being
delivered for the old instance, you could be confused by that. Careful
use of the udata field in the event data structure can help protect
against such "recycle races."

Sadly, in Darwin 7.x (Mac OS X Panther 10.3.x), the EVFILT_MACHPORT is
still a "future" feature. When it does make it into the system, you
will see an event structure that identifies the Mach port name that has
data, the size of the head message on the queue, your udata, etc...
There will also be support for no-more-senders notification
indications. But as I said, it's not there yet.

The EVFILT_FS mechanism is in place now. It provides for notifications
at the "whole filesystem" level. If you ever get disconnected from a
network volume and see the new (in Panther) dialog pop up asking if you
want to unmount it (rather than potentially leaving your volume and all
of its users hung), this is the mechanism at the root of that
experience.

> Another thing you might want to look at re: your sample code is the
> usual OS X document save scheme (Cocoa for example, but I suppose the
> FSSpec file swap works the same way), which goes like:
>
> 1. Rename old file.
> 2. Save new file at old file's name.
> 3. Delete old file.
>
> This means when I run a kqueue with EVFILT_VNODE, strangely enough I
> don't see the first rename, but I see the delete, at which stage the
> vnode I'm monitoring is defunct and I have to reopen the vnode to
> monitor again.

Not strange at all, since renaming a file doesn't modify that file at
all (just [one of] the parent directories that refer to it). If you
were monitoring the parent directory, you would have seen the event for
that rename.

--Jim

[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: kqueue on OS X (From: Glen Low <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.