Re: [PATCH] POSIX message queues, 2.5.50

[Manfred Spraul <manfred@colorfullife.com>]

Krzysztof Benedyczak wrote:

>wait_event is rather not good as I don't have condition to check - in that
>case I just place process in a queue and wait for wake_up.
>But I agree that it is ugly - I used it only as a quick fix for one bug.
>Now I think I have good solution but I have to test it first.
>  
>
The bad thing is that you use __add_wait_queue() and call the wait queue 
locking functions yourself. This is not needed. The only function that 
was permitted to do that is sleep_on(), and that will die soon. I've 
quoted sleep_on as a reminder to kill that code in kernel/sched.c.
Just use add_wait_queue() instead of the internal functions. Or 
prepare_to_wait/finish_wait, that has a slighly lower locking overhead.

Btw, could you explain how your message priority implementation works?

If I understand it correctly, wq_add maintains a priority sorted linked 
list. wq_sleep() waits until the process becomes the first entry in the 
priority queue.
- You use the pid value as the thread identifier - why? Usually the task 
struct pointer is used within the kernel.
-  Is it correct that wq_wakeup wakes up all processes that sleep in 
wq_send, and then the highest priority process continues? What about 
waking up just the highest priority process? Look at the wakeup code in 
ipc/msg.c - it implement message types that way. The sender looks 
through the list of waiting receivers, and directly sends the message to 
the right receiver [pipelined_send()]

--
    Manfred