[lkml]   [2002]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] POSIX message queues
some comments as asked for:

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 PROCESS_SHARED mutexes and condvars in NGPT we have that - and I am
in the process in converting the mmap() based implementation of
Richard Stevens in UNPv2 onto Linux.

The messages are stored in shmem and the library routines access the
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
(yes, then your system is screwed anyway).
BUT the messages are not copied between user- and kernelspace like they
in SysV msgsnd.

POSIX mqueues have "kernel persistence", i.e. they live until
mq_unlink() is called.
They do not vanish with the creator on exit().
Without rlimits you can easily consume all available kernel memory (DoS)
by creating
a mqueue and filling it with garbage.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:2.443 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site