<[EMAIL PROTECTED]> <a05101500b8da6b71d11d@[129.46.156.156]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <a05101500b8da6b71d11d@[129.46.156.156]>; from [EMAIL PROTECTED] on Wed,
Apr 10, 2002 at 03:23:13PM -0700
Randall Gellens on Wed 10/04 15:23 -0700:
> > > I still think the lock should surround the session and let MDA
> > > handle temporary errors, but maybe that is bad policy, I don't
> > > know.
> >
> > One problem with that solution is that lock is by convention
> > considered dead and removable by the MDA after 6 minutes, and a POP
> > session can go longer.
>
> You can add calls on Qtouchlok() to refresh the dot lock periodically
> during the session, as is done currently in pop_dropcopy.c and
> pop_update.c
Qtouchlock eh? Ok which operations can cause time to elapse:
- POP_TIMEOUT already is 120 seconds
- pop_timeout is controlled by the admin
- update already uses Qtouchlock in its unbounded loop
- dropcopy already uses Qtouchlock in its unbounded loop
- user could do nops to reset idle counter, how about touching
the lock in tgetline() to solve this? no, no...
- pop_send() is potentially unbounded, maybe touch in
pop_write()?
- other commands
ok nevermind that, how about setting an alarm every time we execute a
command which can run in unbounded time, and we're running under a
full-session-lock. When the alarm is raised the handler refreshes the
lock and resets the alarm, then returns to continue doing work. We
already have the lock path in szLock[] global so it will be available
from the handler. The alarm will be conditional on full-session-lock
option and everything will work unchanged without it. When we exit a
command we restore the alarm be used just as tgetline() already does.
Does that sound reasonable? I'm sure I'm missing something.
