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
structures
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.
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 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/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:28 EST