cpu: native: don't handle pending signals in isr_thread_yield

[kaspar030]

I've been hitting a bug were a thread wouldn't get scheduled anymore even after putting it on the respective runqueue.

I think the problem is a possibly nested call of isr_thread_yield():

1. ISR (e.g., incoming network packet) triggers
2. ISR sets a thread's status, calls thread_yield_higher() to trigger context switch
3. thread_yield_higher() calls isr_thread_yield()
4. isr_thread_yield() previously handled pending signals using native_irq_handler()
5. native_irq_handler() calls cpu_switch_context_exit()

... somehow now the thread woken up by 2.) doesn't get scheduled anymore.

I don't know why (tm), but removing the pending signal handling from isr_thread_yield() solves this.

[OlegHahm]

I think I found something similar when reviewing #2071.

[OlegHahm]

#2071 (diff)

[OlegHahm]

(And in my working branch for the 1000-native-nodes experiments, I have the same diff: OlegHahm@9930e17)

[kaspar030]

@LudwigKnuepfer could you take a look?

Aren't IRQ's (signals) queued if not handled here?

If not, we need to get rid of the cpu_switch_context_exit() call. One way would be to have a version if native_irq_handler() which does not call it.
And we should probably make sure that isr_thread_yield() doesn't nest.

[LudwigKnuepfer]

I can't estimate when I have time to investigate this properly. I would advise to try and figure it out on your own unless it can wait for at least two weeks.

[kaspar030]

I cannot reproduce anymore. Reading through the description, this should be fixed by #6660.