On Thu, Dec 28, 2000 at 12:23:12PM +1300, Dan Langille wrote:
> On 27 Dec 2000, at 19:56, Peter Pentchev wrote:
>
> > On Wed, Dec 27, 2000 at 09:16:34AM -0800, Alfred Perlstein wrote:
> > > * Dan Langille <[EMAIL PROTECTED]> [001226 23:50] wrote:
> > > >
> > > > My idea is to have a daemon, or something resembling one, sitting on
> > > > the box watching the directory. When a new file appears, it starts a perl
> > > > script. This perl script is beyound the scope of my question, but it
> > > > processes all the files in the directory. When finished, it looks for any
> > > > more files and repeats as necessary. If no more files, it exits.
> > > >
> > >
> > > This isn't an answer to your main question (i see it's already been
> > > discussed), but you may be able to use setup a kevent on the
> > > directory which should inform you if any files are added to it.
> >
> > Unfortunately, I gather that Dan intends to write most of the FreshPorts
> > code in Perl, and AFAIK, Perl has no kqueue/kevent interface :(
>
> Unfortunately? *grin* FWIW, Most of the existing and new code will be
> PHP based. Perl is used primarly for importing data from cvs-all. And
> for various mailings out to users.
The 'unfortunately' part was not to say that I don't like Perl, or that
I don't think it should be written in Perl; rather, that at the moment,
Perl has no easy way of using the kqueue/kevent interface. If there were
such an iface for Perl, it would all be done with one little filter
invoked from procmail to write the message, and one sleepy Perl thing,
idling in an kevent() call most of the time, and only waking up when
there are changes to the dir.
Hmm. On second thoughts, I wonder if the sleep/opendir method might
not work better under temporarily high load - even better than the
cron-based one. If a bunch of mails arrive at the same time.. hmm
I should play around with kevent to see how it could handle this -
notifying me for each and every message could be suboptimal.
The sleep/opendir way would process as many new messages as there
have arrived; ditto for the cron-based one, *except* that if there
are too many messages, there could be two or three Perl interpreter
invocations, which find an old script still running, and die quietly,
having used up some CPU resources in the meantime.
> > Thus, to make use of kevent (which I certainly agree would be a better
> > FreeBSD-specific solution), he'd have to either 1. have a C program
> > which spawns Perl and his script on every change, or 2. have a C program
> > which spawns Perl once and signals it on every change.
> >
> > The first way would be downright stupid IMHO.. The second one may
> > very well be more efficient than the readdir, sleep solution which
> > I proposed in other postings, seeing that Dan wants to process
> > the cvs-all mailings, which certainly do not arrive every few seconds :)
>
> I like the 2nd concept. It appeals to me. I haven't done any C in about
> 7 years and all of that was in Windows. Never in a Unix environment.
> This solution is more complex than the "cron job every minute" which I
> discussed with Mark, but it fits with my goal of having processed the
> cvs-all messages as quickly as I can.
I could play around with kevent in a couple of days to see how it
behaves when multiple messages arrive. When a file or multiple files
arrive, the sleeper would have to go through the opendir/readdir
dance, and either only process the first file it finds, or process them
all. In the second case, if multiple files should arrive, those would
be all processed in response to one event, and the next events would
trigger lots of opendir/readdir/closedir calls with no files found.
Hmm.. as a side note.. I'm not quite sure how kqueues operate on
vnodes. If I should request an EVFILT_VNODE filter with NOTE_WRITE,
receive an event, find a new file, then unlink() it (which involves
writing to the vnode I'm monitoring), will *my* write generate
another event I'd have to process?
G'luck,
Peter
--
You have, of course, just begun reading the sentence that you have just finished
reading.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
