On Sun, Jan 04, 2009 at 11:09:32AM -0800, Arjan van de Ven wrote: > On Sun, 04 Jan 2009 20:05:26 +0100 > Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > > Surely the thread should die again boot up? On module load > > synchronisity is usually not a problem. > > sadly that's not correct in practice based on the fast boot work we've > done. Hmm, but I'm not sure your current code is module safe, in particular against unloading again. You would likely need a barrier at the end of module load at least. > > > > > Personally I think it would be better to make this more generic. > > Various subsystems have thread pool implementations now, > > sort of kinda. If a good one appears I'd be happy to build on top of > that, assuming it's generic enough. I think you can just create a separate barrier primitive which will work independently of any special thread managers. > > > and this > > is just another variant that except for the sequence stuff > > isn't all that much different. So it would be better to have > > a generic worker thread manager that just supports these > > barriers too. > > ... or maybe think about seeing this system as exactly that thread > manager? I'm not sure it's generic enough. -Andi -- ak@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
