Re: kqueue on OS X

• Subject: Re: kqueue on OS X
• From: Glen Low <email@hidden>
• Date: Wed, 18 Feb 2004 22:21:11 +0800

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.

• Follow-Ups:
  • Re: kqueue on OS X
    • From: Jim Magee <email@hidden>

• Prev by Date: Re: C linkage error with Netxx and other libs
• Next by Date: Re: kqueue on OS X
• Previous by thread: Re: kqueue on OS X
• Next by thread: Re: kqueue on OS X
• Index(es):
  • Date
  • Thread