Subject: Re: "knowing" when a file is available in a directory
To: None <port-i386@netbsd.org>
From: Eric McWhorter <emcwhorter@xsis.xerox.com>
List: port-i386
Date: 10/06/1999 13:29:15
der Mouse writes:
 > >> How quickly do you need detect the new file?  you could poll once a
 > >> second for a change in modification time on the directory.  On a
 > >> local filesystem it shouldn't be too painful..
 > > As things are, the printer will outrun any single CPU computer by a
 > > fair margin, so any idle time on the computer is categorically a bad
 > > idea.
 > 
 > Not if there are no jobs queued. :-)

You missed lots of cases.  An app can crash, power can fail, or the
computer could spontaneously mutate into a toadstool and beam itself
to alpha centauri.  Under all these circumstances and the one you
mentioned the printer will not "outrun" the computer.  Making a
command decision here, I'm not going to tune the app for any of these
cases.

 > > Also, polling on a one second interval would limit the printer to (an
 > > upper bound of) 60 print jobs a minute, which would be too slow.
 > 
 > Not if you can handle more than one job per poll.  (What, you have a
 > >1pps printer?)

I should have said worst case rather than upper bound.  Xerox builds
>1pps printers.

 > Alternatively, you could poll immediately after completion of a job and
 > fall back to interval-based polling only if a poll shows nothing queued.

There will always be work to do (famous last words), so I'd rather not
check unless there is a reason to.  What I want to do is poll a
directory based on a kernel event, rather than a timer.  It still
boils down to a poll since not all kernel events are for my benefit,
but the probability of a meaningful poll would be higher.  I think I
have my answer.  Can't do that.

 > > [...] I'd probably get better performance by getting the receiving
 > > process to somehow cooperate.
 > 
 > If you have control over the process that's dropping these things in
 > the queue, yes, I'd say you probably would be better off having it do
 > something like sendto() an AF_LOCAL socket to kick the daemon, or read
 > a PID from a file and send a signal, or something.

I'd rather assume control of the receiving app then poll on a timer.
If it were possible to poll on something meaningful, I might be able
to avoid working on the receiving app.  Having to work on the
receiving app is by no means a show stopper.  I can live with it.

Thanks for all the replies!

-- 
Eric McWhorter
Xerox Special Information Systems
emcwhorter@xsis.xerox.com