10 More Discussions You Might Find Interesting
1. Programming
hello, I try to test the POSIX mq_open function on book unp like below:
#include "unpipc.h"
# include <mqueue.h>
int main(int argc, char **argv)
{
int c, flags;
mqd_t mqd;
flags = O_RDWR | O_CREAT;
while ((c = getopt(argc, argv, "e")) != -1) {
... (3 Replies)
Discussion started by: anpufeng
3 Replies
2. Programming
Hi,
I wanted to know whether the POSIX message queues are statically allocated memory by the kernel based on the parameters specified in the open or as and when we send messages, memory are allocated?
Does the kernel reserve the specified memory for the message queue irrespective of whether... (1 Reply)
Discussion started by: sumtata
1 Replies
3. Programming
in a single main() function,so need signal handling. Use Posix Message Queue IPC mechanism , can ignore the priority and other linked list message,to implement the scenario:
client:Knock Knock
server:who's there
client: Eric
Server:Eric,Welcome.
client:exit
all process terminated
... (1 Reply)
Discussion started by: ouou
1 Replies
4. Programming
Hello,
I am trying to implement posix message queue application. I am faced with an error on the mq_receive section. It says "Message too long". I've tried couple of small tweeks, but to no result. Please do suggest any rectificaitons.
mq_send section-works successfully
#include... (2 Replies)
Discussion started by: katwalatapan
2 Replies
5. Programming
Hello !!!!! I have a simple question but i can't find the answer anywhere hope to meet it here.
Why it is a bad idea to pass pointers through message queues ?
Most structs i see all of their char types are arrays... Is it becase having pointers means we could possibily send wrong bytes ?
For... (2 Replies)
Discussion started by: qlyine
2 Replies
6. Programming
Hii can anyone pls tell how to limit the max no of message in a posix message queue. I have made changes in proc/sys/fs/mqueue/msg_max
But still whenever i try to read the value of max. message in the queue using attr.mq_curmsgs (where struct mq_attr attr) its giving the default value as 10.... (0 Replies)
Discussion started by: mohit3884
0 Replies
7. Linux
Hi all,
Please tell me how to change POSIX message queue maximum size? "ulimit" is not a solution because it controls shell resources. But i need to control queue size before login in and starting the shell. It is needed to limit queue size for applications started before login in.
Sorry for my... (7 Replies)
Discussion started by: Vourhey
7 Replies
8. Programming
Hello,
i need to write a message queue "chat server", that should work only localy.
Can anyone please help me with some ideas and peshaps code. I'm studying the UNIX IPC mechanisms right now. So far, i understand how it works but i still cannot get an idea how to write a chat programm...
... (2 Replies)
Discussion started by: etenv
2 Replies
9. HP-UX
Hello,
My question is related to "pipcs -qa" command under HP-UX 11i PA-RISC 64 bits.
We have a little C program that creates posix ipc message queues using the mq_open() system function.
The program fail with 'No space left on device' error when we create big queues. What is the system... (6 Replies)
Discussion started by: cadanir
6 Replies
10. Programming
Hi there:
Thanks first. When I use a message queue amony severl processes, will I have to synchronize the queue? I don't think I would have to because a message queue is implemented in a link listed. Correct me If I am wrong... (0 Replies)
Discussion started by: yanhu
0 Replies
aio_req_per_thread(5) File Formats Manual aio_req_per_thread(5)
NAME
aio_req_per_thread - desirable ratio between number of pending AIO requests and servicing threads
VALUES
Failsafe
Default
Allowed values
Recommended values
DESCRIPTION
The implementation of POSIX AIO on HP-UX uses kernel threads to perform I/Os to filesystems that do not directly support true asynchronous
I/O. (This distinction is transparent to the user.) The kernel threads are organized into worker-thread pools (called AIO thread pools)
created on a per-process basis. Since a thread pool mechanism for I/Os introduces a variety of trade-offs concerning utilization of CPU
time vs. I/O resources, four dynamic tunables are available to customize the behavior of this thread pool: aio_proc_threads(5),
aio_proc_thread_pct(5), aio_req_per_thread(5), and aio_monitor_run_sec(5). Please see individual manpages for details on each of these
tunables.
The tunable specifies, on a per-process basis, the desirable ratio between the number of pending POSIX AIO requests and the number of
threads in the AIO thread pool.
The number of threads in the AIO thread pool is bounded by the tunables and but the tunable determines how the AIO thread pool behaves
within that bound. determines how much the AIO thread pool grows as the number of outstanding AIO requests grows, by defining how many
I/Os each thread will be responsible for.
Who Is Expected to Change This Tunable?
System administrators that run applications requiring heavy usage of POSIX AIO to filesystems.
Restrictions on Changing
This tunable is dynamic. Changes to to this tunable take effect immediately for new processes started after the change. They also impact
existing processes, but the speed with which the changes propagate to running processes is determined by the tunable
When Should the Value of This Tunable Be Raised?
should be raised for applications that want to limit the number of threads used by the POSIX AIO subsystem. Applications would want to do
this to either free up more process threads for other work, or to limit the level of concurrency inside POSIX AIO, perhaps to reduce load
on physically limited I/O devices.
What Are the Side Effects of Raising the Value of This Tunable?
By allowing less threads for POSIX AIO requests, concurrency is reduced and AIO I/O requests will have to wait longer for servicing. This
can result in increased latency and reduced POSIX AIO performance on systems whose I/O stack could otherwise handle heavier loads. On the
other hand, less threads per request can result in less context switching, reducing the CPU utilization of POSIX AIO.
When Should the Value of This Tunable Be Lowered?
should be lowered when applications want to maximize the concurrency and performance of POSIX AIO requests. This should be done when an
application does not need a large number of threads for other work.
What Are the Side Effects of Lowering the Value of This Tunable?
Lowering this tunable results in more threads being used by POSIX AIO to handle I/O requests, which could increase CPU usage and use up
threads that applications might need for other work. On the other hand, POSIX AIO performance should increase.
What Other Tunables Should Be Changed at the Same Time as This One?
interacts with this tunable by setting a strict limit on the number of threads that can be used for POSIX AIO.
interacts with this tunable by setting a limit on the number of threads that can be used for POSIX_AIO, but does so based on a percentage
of the maximum number of allowable process threads. This allows the AIO thread pools to respond dynamically to changes in
defines how often (in seconds) the AIO thread mechanism will monitor itself for adherence to the constraints defined by the tunables above.
WARNINGS
All HP-UX kernel tunable parameters are release specific. This parameter may be removed or have its meaning changed in future releases of
HP-UX.
Installation of optional kernel software, from HP or other vendors, may cause changes to tunable parameter values. After installation,
some tunable parameters may no longer be at the default or recommended values. For information about the effects of installation on tun-
able values, consult the documentation for the kernel software being installed. For information about optional kernel software that was
factory installed on your system, see at
AUTHOR
was developed by HP.
SEE ALSO
kctune(1M), sam(1M), gettune(2), settune(2), aio_proc_threads(5), aio_proc_thread_pct(5), aio_monitor_run_sec(5).
Tunable Kernel Parameters aio_req_per_thread(5)