On Sunday 29 October 2006 03:41, Paul Allen wrote: > Let us suppose that this M:N business is important, perhaps something > to consider is why and whether the kernel has so much knowledge of it. > > If I read Matt Dillon's comment closely enough, I believe his precise > recommendation was not "something like kse as Julian read it" but > rather something where this M:N component was entirely part of the > userland threading support and therefore would just go away or not > depending on which library you linked with. > > I think posix might require a global priority space though... > Yes, I think if libpthread wants to implement POSIX priority mutex and SCHED_FIFO, SCHED_RR for system scope thread, it should work out a way to unify priority for all process scope and system scope threads, it has to support it if we want to implement process-shared mutex, current we can not but other OS can, I found Solaris's M:N implementation will bind a M:N thread on a LWP once it has owned a PRIO_INHERIT or PRIO_PROTECT mutex and raise the LWP's priority, fix me if I am wrong. Solaris now favors 1:1. > Anyways it remains dubious in my mind that the kernel should allow > a user to create many processes but penalize creating threads. > > The only reason I can think of is that you expect people to be sloppy > with their threads and careful with their processes. > > Still if I am ray-tracing why should I need to make a point of picking > my thread/process balance to get around your mechanism. If fairness > is the goal why am I even allowed to do so?Received on Sat Oct 28 2006 - 22:27:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC