Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: Re: Proposed changes to threading API

Re: Proposed changes to threading API

From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Mon, 7 Aug 2006 20:40:46 +1000

/me backs away... quickly...

On 07/08/06, Daniel Stenberg <daniel_at_rockbox.org> wrote:
> On Mon, 7 Aug 2006, Jonathan Gordon wrote:
>
> (This has nothing to do with Dan's original questions. I thought his
> suggestions looked fine!)
>
> > is there any reason why the thread has to stay on one core?
>
> Simplicity? Why would a thread "move" between cores?
couldnt you have a problem where one core could be asleep and the
other core be thrashing away _at_ 100% ?
>
> > And on the topic of threads, what about changing to prioritising
> > threads? especially the audio thread.
>
> Whoa! Why would we want that? And if so, how would it work?
>
> > And lastly, put in a schedular so threads dont have to explicitly yield
> > (maybe this will stop the problem where you have to reset if the ui thread
> > crashes but audio/backlight still work?)
>
> Gosh. Abandoning the cooperating multi-tasking of current Rockbox will open
> all gates to hell and lead to no good. We'll need a bazillion locks, mutexes
> and similar things and then still have to debug for thread-related problems
> and dead-locks for many months/years ahead.
>
> I'm strongly in favour of keeping our current simple threading system. KISS.
>
> --
> Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
>
Received on 2006-08-07

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy