This patch adds functionality to request an asynchronous notification
if some other process has send a message to it. We currently send a
SIGALRM to avoid any changes to core infrastructure of signal handling.
Ideally we should implement a separate signal for this. Currently there
is an obvious disadvantage of not being able to use SIGALRM with alarm,
if we are using this functionality.
Currently we only allow users to get and set number of queues. The
operation is always non blocking. There is no provision for non
blocking operation at the moment.
The queue sizes are set to MAX 256 by default. If a user changes the
attributes and sets the queue size or number of messages in a queue
to less than 256, it is the responsibility of the user to close any
queues which were opened with a descriptor greater than the value
currently set.
For example, by default queue sizes are 256. If 150 queues are opened
and then the user sets the number of queues to 32, all open descriptors
and queues from 32 to 150 must be closed. Note that descriptor number
allocation starts with zero and not one.
Fixed the following bugs:
1. Message priority was not set at all at two places
2. Limits check was not correct while returning error values
3. We are suppose to allow multiple users operate on the same queue
using a named descriptor. However any one user calling close before
the other would result in closing the queue even when other users
might be using it. Track number of users and close only if number of
users is zero. Yet to do functional tests for this, so this is untested,
but introduce it anyway at this juncture.
Implement message queues support for Minix.
Pending tasks:
Blocking or non blocking for send receive?
Sort by priority and time?
Test codes?
Bug fixes?
Sanchayan Maity