Re: Re: Errno::ENOMEM (but now with no reason)

["Iñaki Baz Castillo" <ibc@aliax.net>]

El Domingo, 10 de Enero de 2010, Eric Wong escribió:
> > In fact, let's say process A is readin in /mq and B is writting there.
> > I delete /mq (with POSIX_MQ.unlink or by deleting /mnt/mqueue/mq) and A
> > still  can write and B still reads what A writes.
> 
> Hi Iñaki,
> 
> mq_unlink(3) and the normal unlink(2) system calls are very similar.  if
> another process has the queue open, the queue stays alive until the last
> process with the queue open closes it.  So what you're seeing is
> expected behavior (see the mq_unlink(3) manpage or the POSIX_MQ#unlink
> RDoc).
> 
> Continuing to use an open but unlinked file is common in Unix
> applications.  This naturally extends to message queues as well.

Yes, I expected it.


> > So IMHO it's not a memory allocation problem (it didn't make sense it to
> > be)  but other kind of problem (trying to create a queue that still is in
> > use even if it was "theorically" deleted). Could it be detected?
> 
> Actually, it is a memory allocation problem.  "ulimit -q" is for the
> user and all processes the they own.  On Linux, the getrlimit(2) manpage
> (under RLIMIT_MSGQUEUE) documents this behavior.

So, the problem I was experimenting was because I tried to create a new mqueue 
when the previous one still existed (even if it was unlinked).
Ok, thanks a lot for your explanation.


-- 
Iñaki Baz Castillo <ibc@aliax.net>