[En-Nut-Discussion] CVS Commits

[Harald Kipp]

Ralph,


>It seems the same could be accomplished by just removing the thread from 
>the runQueue and saving it a killedThread then calling NutThreadSwitch(), 
>probably a better implementation.
>Off hand I can't think why I used the 255 priority or see any benifit in 
>it over the above.

I think I'll remove this special meaning of the priority
again. Just wanted to make sure that this won't disable
any smart idea I didn't recognize.

>I guess I found it just as easy to call NutThreadExit at the end of the 
>thread function. The compiler always warns you if you exit the noreturn 
>function so it's easy to spot where you should have NutThreadExit.

OK, NutThreadExit is sufficient and doesn't require any
change of the thread's entry code.



>The possibility of reentrant/nested interrupt handlers is an interesting 
>idea, and clearly complicates an interrupt stack. Solutions are not hard 
>to imagine but you need to consider (IMHO) that if you are doing something 
>that takes that long you should be doing it in user mode 
>anyway.  Interrupt handlers should be fast in quick work and out of there.

In general, I agree. But MP3 feeding is a bit different.
The latency between NutEventPostAsync and releasing
NutEventWait may cause an out of data in the MP3 decoder
on very high bitrates. That's the disadvantage of
cooperate multithreading. Feeding the decoder in the
interrupt routine avoids this problem. But I must admit,
that my first MP3 decoder driver was for a 3.6864 MHz
ATmega103, the 14.7456 MHz ATmega128 may significantly
reduce the problem.


>This might be of interest 
>http://www.avr1.org/pipermail/avr-gcc-list/2003-January/003385.html, avrx 
>supports it appears supports nested interupts on a seperate stack.

Haven't looked to Larry's code for a long time.
Would be a good idea to do that.

Finally, it's a good point to take care, that the
simplicity of the Nut/OS kernel is preserved.
That reminds me of Mike Cornelius' comment about
NutEventPostAsync, which looks like a good target
for code reduction.

Thanks,
Harald