Re: Filters with multiple copies of pine running

On Mon, 5 Feb 2007, Ryan Barrett wrote:
> On Mon, 5 Feb 2007, Ross wrote:

>> As long as the INBOX contains the message, though it may be 
>> marked as deleted or in any fashion, both copies of Pine will 
>> read (& probably cache) the message. Any filter will then 
>> process the message accordingly. So if both copies of Pine 
>> process the message with the same designed filter, two copies 
>> of the message will be processed accordingly, & the receiving 
>> folder will end up with two copies of the same message.

> this is what transactions are for. if filtering is 
> transactional, only one instance of pine will perform a given 
> filter. after that, the message will be moved or changed such 
> that it won't trigger the filter in the other instance.

> having said that, i doubt IMAP allows arbitrary transactions. 
> pine does obey a mailbox locking protocol, but i suspect that's 
> unrelated.

Each application of Pine is only aware of each other if 
file/record locking is implemented, there might be a few other 
instances but for this problem locking is the only issue I can 
think of.

A move filter/command declares an expunge will take place, & 
should lock the file/message/record for a read to secure all 
records of the file & avoid a crash. I do not know if Pine does.

So unless there is a delay between the Pine applications allowing 
one application filter to complete the process where the 
message/record is finally expunged from the INBOX file before the 
second Pine application arrives to read, or the application of 
Pine that arrives first locks the file/record for a read & blocks 
the second Pine application from reading, both Pine applications 
will read & copy the message/record, only seeing each other at 
the destination folder to take turns locking to save the 
message/record there. Then one application will lock the INBOX 
file first to expunge the message/record, the message move 
completed by that one application.

I would hope the second Pine filter application would not then 
try to lock the INBOX & expunge the same record number, as that 
might expunge the next message, the following record renumbered 
following the prior expunge, & a message would be lost. Yes, 
there is a race there that could be dangerous unless Pine 
protects the move function.

Obviously the results you see, two copies of the same message in 
the destination folder, indicates something is wrong with the 
process. Yet I would expect it with the dual application & 
present filter design, unless Pine enabled read locking for a 
message move.

Who wrote or works with the Pine code that could tell us more?

--
RossARR
[email protected]
mrossarr.nixsyspaus.org/
nixsyspaus.org=208.64.38.250
---end-of-message---
_______________________________________________
Pine-info mailing list
[email protected]
http://mailman1.u.washington.edu/mailman/listinfo/pine-info