[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Thread implementations... poll() on regular files
Richard Gooch wrote:
> Dean Gaudet writes:
> > On Tue, 23 Jun 1998, Richard Gooch wrote:
> > > ext2? You mean regular files?
> > Yeah.
> You currently can't poll for when a regular file delivers the block of
> data you asked for. I'm not aware of any UNIX that supports this.
> This is a whole new can of worms than the implementation of completion
> ports/whatever.

interesting can of worms, but.
worth playing with.

it gives a userland interface to all sorts of things which currently
do happen, but are hidden in kernel (supporting buffer-cache, knfs, dcache, ...)

consider what happens if poll() gets extended to all vfs objects...
and readdir() returns add/delete/change events, optionally on subdirs, too.

"tail -f" loses it's sleep(1), and reduces to poll()

"find ..... -poll" keeps files/dirs open, awaits any inode change,
and utters the name (and -printf"..." details) of altered inodes

"make --persist" accumulates a bag of fds for everything it ever stat()'d,
and checks for up-to-date-ness on each twitch. No, too many fds!
But consider what happens if you just keep the dirs open -- much lower o'head.

daemons which scan a spool dir need only opendir("...", ONONBLOCK),
readdir() the static entries to eof, then poll() for changes.

All of the above suggest kernel bloat & extra overhead, but when such concepts
are needed by an application, they're currently accomplished much less efficient
userland versions -- the challenge is finding space-efficient kernel
representation which wastes no time when not utilised, and much less than the
userland alternative when they are used. Ideally piggybacking on existing kernel
concepts (which most of it does).

readdir() and find would have to grow to embrace a different object type,
the recently-expunged entity.
But that's supported in many places already -- ext2's dtime, negative dcache
entries, stat's ENOENT.

An all-embracing poll() allows user-level access to waitq and notify concepts.
I had a low-impact mudmap of the concept somewhere, time to dig it out again.
Requires a sort of preemptible resource locking, where (one/all of) a list of
interested parties are notified when a lock is released.
Difference is that said parties don't ever acquire the lock, they just sniff
around it whenever it rattles (equivalently, they do (collectively) acquire
the lock in a multi-snooper-multi-reader-one-writer sense, where snoopers
are readers w/o the right to *lock* it, but just get notified with a
callback when the lock gets grabbed from under them).
Since i last played with this, linux has grown a notify concept, which could?
be stretched to fit, i think.

i suspect the main reason it's never been attempted in the past is the great
simplification of security hacks, where one can do
fds[0].fd = opendir("/tmp", ONONBLOCK);

for (;;) {
poll(fds, 1, -1);

// see if we've caught any interesting
// switch+grab possibilities
while (readdir(fds[0].fd, dirent...) >= 0) {
if (!strncmp(, "mail-temp-prefix", 16)) {
// try an insecure-mail-handler exploit
} else .....

these usually spin on readdir() or stat("/tmp"), thus their priority goes
down enuff that the window-of-opportunity slams shut on their fingers.
With a publicly-scrutinised gnu/linux toolset, the number of such holes
goes down rapidly, especially since the same principle can be employed
in satan-for-filesystems type security monitors.

does this enthuse anyone?
It's not new.

It seemed to be implied twixt the lines of the original 4bsd manifesto's
everything-is-a-descriptor concepts. i certainly saw it there,
back in the days when symlinks were young, and had '@' in their names.

[see also plan9, recent Lucent stuff, ....]

But such grand-unified-theory-of-namespaces dreams got quiely buried by the
USG's market-driven KISS, which kept all complexity hived off into separate
corners, to avoid startling the horses. Witness sysv-shmem, which refused
to have vfs access (/proc/shm/*) on the (not insubstantial) grounds that
VMS-pundits would mutter "psst, that unix shit puts shared-memory on *disk*".
POSIX shared-mem has at last done a mount() of shm, msg, ...!
I'd like to do the reverse, and extend kernel's event system out thru vfs.

Linux is getting to the point where these concepts can be bridged, with almost
no cost to internal complexity, as the scaffolding already bridges most
gaps for other reasons. One day i'll string a rope across & pull them together.

People have been selling big, heavy custom bridges across this space for years.
They're called DBMSs, and they've traditionally sucked every concept they
touched inside themselves because they couldn't be built around simple portable
event-aware interfaces, as a sufficient set didn't exist.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.109 / U:0.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site