>(it would be cleaner to use POSIX semaphores for this, but you mentioned >the requirement for the mechanism to work on 2.4 kernels too - pthread >spinlocks will work inter-process on 2.4 too, and will schedule nicely.)
can't work. pthread interprocess spinlocks are hopelessly non-RT safe in 2.4/linuxthreads. or they were the last time i looked - they rely on sending signals and passing through the whole pthread layer. this is why we use FIFO's right now: fast, portable (though not to OSX <grin> - we have to use Mach ports to get enough speed there), and a PITA :) >well, no. Unless i misunderstood your application model, you want >threads to sleep until they are woken up. So you want a very basic >sleep/wake mechanism. But yield_to() does not achieve that! yield_to() >will yield to _already running_ (i.e. in the runqueue) threads. Using >yield() (or yield_to()) for this is really suboptimal. By using a futex >based mechanism you get a very nice schedule/sleep pattern. i mentioned earlier today in a message to bill huey that JACK is really a user-space cooperative scheduler. JACK's "scheduler" knows who is doing what and when, and if it doesn't then it can't work at all. so the scenario you describe is impossible and/or broken. please keep in mind this description of JACK. there is no doubt some remnant of the work i did on scheduler activations in the mid-90's left floating around in my head and shaping JACK in mysterious ways :) --p "kernel-to-user-space: thread <tid> blocked on disk i/o. please advise." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
