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