Messages in this thread |  | | Date | Sat, 31 Aug 2002 14:53:54 +0200 (CEST) | From | Krzysztof Benedyczak <> | Subject | Re: [PATCH] POSIX message queues |
| |
Hello,
On Thu, 29 Aug 2002 pwaechtler@mac.com wrote:
> I know that it's nowhere stated, but POSIX mqueues are perfectly > designed to be > implemented in userspace with locking facilities provided by the system. > ... > with proper locking. I am not very happy about the fact, that with > futexes the whole > cooperating system get stuck when 1 process crashes inside a critical > region > (yes, then your system is screwed anyway). > BUT the messages are not copied between user- and kernelspace like they > are > in SysV msgsnd. Is coping between user and kernel spaces so bad? As you pointed out there are problems with only user space implementation.
> POSIX mqueues have "kernel persistence", i.e. they live until > mq_unlink() is called. > They do not vanish with the creator on exit(). Yes. But I don't see what is wrong with our system? Our queues _don't_ vanish with creator exit. (Our add on to exit() (and fork) is to keep track of processes that have opened mqueue. Then mq_unlink() can postpone deleting queue to the time when it isn't opened by anyone)
> Without rlimits you can easily consume all available kernel memory (DoS) > by creating > a mqueue and filling it with garbage. To this I answer in an answer to your next post :)
> > When implemented in kernel space, you have to create a thread with the > brand new > sys_clone_startup (or whatever name it gets) as notification > (SIGEV_THREAD) - which > is SCOPE_SYSTEM, no control about this and not always what is desired. I don't fully understand it. Can you explain it in more details?
Thanks
Krzysiek Benedyczak
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |