Linus Torvalds wrote:
> > I wasn't clear. The sentinel is a local structure on the stack, and
> > only exists while run_task_queue is executing. Another name for this is
> > "deletion-safe pointer".
>
> Yes, except run_task_queue removes every object it finds. So two
> concurrent run_task_queue
On Mon, 18 Dec 2000, Jamie Lokier wrote:
> >
> > Nope.
> >
> > There may be multiple concurrent run_task_queue's executing, so for now
> > I've applied Andrew Morton's patch that most closely gets the old
> > behaviour of having a private list.
>
> I wasn't clear. The sentinel is a local str
Linus Torvalds wrote:
> On Sun, 17 Dec 2000, Jamie Lokier wrote:
> > How about using a sentinel list entry representing the current position
> > in run_task_queue's loop?
>
> Nope.
>
> There may be multiple concurrent run_task_queue's executing, so for now
> I've applied Andrew Morton's patch th
In article <[EMAIL PROTECTED]>,
Jeff V. Merkey <[EMAIL PROTECTED]> wrote:
>
>Try thinking about the work to do model (since task queues are so similiar)
>Having to "kick" these things should be automatic in the kernel. I could
>do a lot of cool stuff with this in there, manos aside.
No, the
On Sun, Dec 17, 2000 at 12:02:31PM -0800, Linus Torvalds wrote:
>
>
> On Sun, 17 Dec 2000, Jamie Lokier wrote:
> >
> > How about using a sentinel list entry representing the current position
> > in run_task_queue's loop?
>
> Nope.
>
> There may be multiple concurrent run_task_queue's executin
On Sun, 17 Dec 2000, Jamie Lokier wrote:
>
> How about using a sentinel list entry representing the current position
> in run_task_queue's loop?
Nope.
There may be multiple concurrent run_task_queue's executing, so for now
I've applied Andrew Morton's patch that most closely gets the old
beha
Linus Torvalds wrote:
> Ho humm. I'll have to check what the proper fix is. Right now the rule is
> that nobody can _ever_ remove himself from a task queue, although there is
> one bad user that does exactly that, and that means that it should be ok
> to just cache the "next" pointer in run_task_q
Linus Torvalds wrote:
>
> On Sun, 17 Dec 2000, Petr Vandrovec wrote:
> > my 2.4.0-test13-pre1 just stopped answering to my keystrokes.
> > I've found that it is looping in tqueue_bh and flush_to_ldisc
> > still again and again.
>
> Thanks, I think you found the big problem with test12.
>
> >
On Sat, Dec 16, 2000 at 07:09:56PM -0800, Linus Torvalds wrote:
>
> which basically will never re-start at the head if a tq re-inserts iself
> (side note: new entires are inserted at the end, but if it was already the
> last entry then re-inserting it will not re-exe
On Sun, 17 Dec 2000, Petr Vandrovec wrote:
> my 2.4.0-test13-pre1 just stopped answering to my keystrokes.
> I've found that it is looping in tqueue_bh and flush_to_ldisc
> still again and again.
Thanks, I think you found the big problem with test12.
> Is current run_task_queue() behavior in
Hi,
my 2.4.0-test13-pre1 just stopped answering to my keystrokes.
I've found that it is looping in tqueue_bh and flush_to_ldisc
still again and again.
To my surprise I found that flush_to_ldisc() does
if (test_bit(TTY_DONT_FLIP, &tty_flags)) {
queue_task(&tty->filp.tqueue, &tq_timer);
11 matches
Mail list logo
