[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a bug of read-passwd

From: Richard Stallman
Subject: Re: a bug of read-passwd
Date: Sat, 22 Jul 2006 00:39:06 -0400

    The problem here is that the new sit-for calls (read-event) to wait
    for new input.  During this time, the process filter takes over, and
    that calls (read-passwd).  While the filter is waiting for the
    password prompt, the sit-for timer expires, which causes a throw back
    to the `sit-for', spoiling the `read-passwd'.

We would want sit-for's timer to be suspended in its operation while
the filter is running.  This should be the case for _all_ filters.  It
does not matter whether the filter does keyboard input.  If the filter
waits for process input, that too will run timers, and the same bug
can occur.

One solution is to set up a mechanism for the sit-for timer
to determine that it has been called inside a filter.
Then it needs to be able to set up for a certain function to be
called when the filter returns.

Another solution would be, don't use a timer.
read-event works by calling wait_reading_process_output.
It should be feasible to give it a new argument
which specifies a maximum time delay.

I think the latter method is cleaner.
What do you think?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]