Re: Something fundamental - how nov works

[Harry Putnam <reader@newsguy.com>]

Dan Christensen <jdc+news@uwo.ca> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>> By writing the data in mbox format to a spool where gnus thinks it is
>> procmail output, slurps it and writes it to the nnml group.
>
> That's what you should do.
>
>> A problem I considered there is the event where my script is writing
>> to the procmail like spool when gnus is slurping.  I guess that is
>> where locking of some kind comes up.
>
> Right.
>
>> [...]
>>   lockfile ~/spool/todo.in.lock
>>    ..[ script action part]...
>>   rm -f  ~/spool/todo.in.lock
>> [...]
>
> This is correct, except that maybe you should check whether lockfile
> succeeds.  (It could be killed while waiting.)  For example:

[...]

> All that "locked" means is that future calls to lockfile will wait
> until the lock file is removed.  In one window, type "lockfile foo".
> In another, type "lockfile foo".  This will wait.  In the first
> window, type "rm -f foo" and you will see the second lockfile return.

Too bad the man page lacks this clear description. Now I get the idea
a little better.

> The idea is that all programs that access the file xxx first
> run lockfile on xxx.lock.  

OK, that seems kind of lame really since it depends on all apps that
might access a file, playing nicely.  But anyway in the instant case,
does that mean that gnus must be told to run lockfile before it
begins to slurp?  Or does gnus know about that already?

Example:  I run my homeboy  script and it is writing to $FILE

Gnus' cron driven batch fetch rolls around and starts fetching right about
that time.  My homeboy script has preceeded its write to $FILE with a
call to lockfile but hasn't yet finished.

Do I need to do something more to prevent bad things happening in that
scene? OR does gnus DTR by itself.