Date: Thu, 29 Aug 2002 23:53:50 +0200
Subject: Re: [PATCH] POSIX message queues
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: linux-kernel@vger.kernel.org
To: golbi@mat.uni.torun.pl
From: pwaechtler@mac.com
Content-Transfer-Encoding: 7bit
Message-Id: <CDB36B91-BB99-11D6-B9F3-00039387C942@mac.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1486
Lines: 42

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/