Sponsored Content
Top Forums Programming POSIX Message Queue - Settings Post 34151 by Deepa on Friday 7th of February 2003 09:13:57 AM
Old 02-07-2003
POSIX Message Queue - Settings

How can I increase the POSIX Msg Q parameter SC_MQ_PRIO_MAX? The maximum is defined as 32. Can I increase the number? If so, how?

Deepa
 

10 More Discussions You Might Find Interesting

1. Programming

a message queue question..

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

2. HP-UX

posix ipc message queue

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

3. Programming

message queue

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

4. Linux

POSIX message queue size

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

5. Programming

How to limit max no of message in a posix message queue

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

6. Programming

UNIX Message Queue

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

7. Programming

POSIX mq_receive issue: Message too long

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

8. Programming

Please help:program hang stuck there signal handling on POSIX Message Queue UNIX C 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

9. Programming

POSIX Message Queue Memory Allocation

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

10. Programming

POSIX message queue mq_open directory

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
process_id_max(5)						File Formats Manual						 process_id_max(5)

NAME
process_id_max - limit the maximum value for process IDs (PIDs) VALUES
Failsafe Default Minimum Maximum must be greater than or equal to If the difference between and inclusive is less than is effectively limited to this difference. DESCRIPTION
The tunable allows the administrator to select a potential value range for process IDs (PIDs) as generated by (see fork(2)). It allows the administrator to select a balance between compatibility, capacity, and aesthetics. Warning: Some programs cannot tolerate PID values up to the maximum. If such programs exist and are critical, the maximum PID should be appropriately constrained. For more details on these concerns, see below. Who is Expected to Change This Tunable? Anyone. Restrictions on Changing Do not increase the maximum PID if there are critical applications which assume that PIDs fit into a restricted range. (See below). The value of can be increased at any time, and it takes effect immediately. (However, its effect may not be noticed until a sufficient number of new processes have been created to cause the system to utilize the available higher values.) A decrease in the value of also takes effect immediately. However any existing processes with PIDs that are higher than the new value are not affected. The decrease will be in full effect for all processes only after a reboot. When Should the Value of This Tunable Be Raised? Increase the maximum PID if the range of PIDs defined by the and tunables needs to be increased to allow the creation of more simultaneous processes. See nproc(5) for limits on the number of processes. Increase the maximum PID in systems which have many active processes (for example, >25,000). The larger range may increase the efficiency of creating of new processes (because it may take less work to find available PIDs). If it is desired to validate that software programs execute properly in environments where PID values may be large, increase the tunable along with the tunable to force all new process IDs to take on large values. (See process_id_min(5) for more information.) Do not increase the maximum PID if there are critical applications which assume that PIDs fit into a restricted range. (See below.) What are the Side Effects of Raising the Value? If the difference between and tunables is less than the number of processes allowed to exist simultaneously is limited to that difference. When Should the Value of This Tunable Be Lowered? Lower the maximum PID if critical applications make assumptions that the PID range is restricted. What are the Side Effects of Lowering the Value? If the difference between and tunables is less than the number of processes allowed to exist simultaneously is limited to that difference. What Other Tunable Values Should Be Changed at the Same Time? It may be desirable to change For program development and validation, a change in the tunable may also be needed. Potential Application Issues The range of PID values has, in the past, been restricted to 0..30,000. Some programs have built-in assumptions about this range. This section briefly describes some of those assumptions. Some application programs have a built-in assumption that a PID does not exceed 30,000 (which was the old value of the (undocumented) and constants). They could fail if PIDs exceed this maximum. Some application programs store PIDs in 16-bit variables (type in C). Such programs could fail if the maximum PID exceeds 32,767. Some programs provide output formats which can be sensitive to the number of digits in the PID. Such programs may produce aesthetically displeasing output if PIDs exceed 5 digits (exceed 99,999). In some cases automatic expansion of output fields can disturb column align- ment. In some other cases, adjacent fields could run together, making the output incomprehensible. Some programs or scripts parse the outputs of other programs which contain PID values. Some such programs have built-in assumptions that a PID will not exceed five character positions. Such a program could fail if the range exceeds 99,999. Because session IDs (SIDs) and process group IDs (PGIDs) are the same as the process ID of the session or group leader, an increase in the maximum PID also increases the maximum SID and PGID. Though much less likely, the same application issues may exist for SIDs and PGIDs. 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. The HP-UX kernel may silently round the selected values for and/or (e.g., to the nearest power of 2) in order to accommodate the PID gener- ation algorithm. Do not increase the maximum PID if there are critical applications which assume that PIDs fit into a restricted range. See the previous section, for more details on such programmatic assumptions. The default maximum (30,000) has been selected to provide compatibility with all such programs. This value should be used if program sensitivity to larger PID values is unknown. See process_id_min(5) for informa- tion about how large PID values can be selected for software validation purposes. Increasing the PID range does not increase the maximum number of processes in the system. 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
fork(2), nproc(5), process_id_min(5). whitepaper, available on Tunable Kernel Parameters process_id_max(5)
All times are GMT -4. The time now is 06:43 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy