unified SysV and Posix mqueues as FS
Quoted 2 lines
- notification not tested
- still linear search in queues
Is that a problem? Receive does one linear search of the queued messages, send does one linear search of the waiting receivers. Both lists should be short.
Could you split your patch into the functional changes and cleanup? (const, size_t, you move a few definitions around, whitespace cleanups)
I don't like the deep integration of the mqueues into the sysv code - is that really needed?
For example, you add the mqueue messages into the sysv array, and then add lots of code to separate both again - IPC_RMID cannot remove posix queues, etc.
Have you tried to separate both further? Create a ramfs like filesystem, store msg_queue in the inode structure? The ids array is only for sysv, only the actual message handling is shared between sysv msg and posix mqueues
Quoted 1 line
+
msq->q_flags|=MSG_UNLK;
Is a "unlinked" flag needed for sysv msg? When a message queue is deleted, all pending writes and reads are cancleled. Copy and paste from shm? shm needs unlinked handling, msg doesn't.
Quoted 1 line
+
msq->q_perm.key=IPC_PRIVATE; /* Do not find it any more */
Does that work? The key is only needed for msgget(), not for msgsnd() or msgrcv()
Quoted 1 line
+
msg_unlock(inode->i_ino);
--
Manfred
Quoted 8 lines · Manfred Spraul
Quoted 3 lines
- notification not tested
- still linear search in queuesIs that a problem? Receive does one linear search of the queued messages, send does one linear search of the waiting receivers. Both lists should be short.
Yes, they _should_ but don't have to be.
It only matters if you ask for specific priority/type of message.
Quoted 9 lines
Could you split your patch into the functional changes and cleanup? (const,
size_t, you move a few definitions around, whitespace cleanups)I don't like the deep integration of the mqueues into the sysv code - is that really needed?
For example, you add the mqueue messages into the sysv array, and then add lots of code to separate both again -IPC_RMIDcannot remove posix queues, etc.
Quoted 5 lines
Have you tried to separate both further? Create a ramfs like filesystem, store
msg_queuein the inode structure?
The ids array is only for sysv, only the actual message handling is shared between sysv msg and posix mqueues
I plan to separate the interfaces and just share the message stuff. But time was getting short. :)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 17 lines · Manfred Spraul
Quoted 3 lines · Peter Waechtler
I plan to separate the interfaces and just share the message stuff. But time was getting short. :)
Ok, you plan to rewrite the patch entirely, and what you have posted is a placeholder.
How would the result look like?
I'm thinking about
- real syscalls
- pipefs like filesystem stub, kern-only mounted, not visible for normal fs operations.
- not using the sysv array
Quoted 3 lines
Could you check the sus standard if that is permitted? A child would inherit the mqueue on
fork().
Yes, I will check that - but I'm afraid of submitting too late.. :(
Quoted 3 lines
For the locking stuff, the patch should probably depend on the sysv rcu patch, it cleans up locking a bit.
BTW, please have a look at ipc/util.c - the spinlock is held once ipc_addid() is called and will deadlock when the array has to grow...
Quoted 17 lines · Manfred Spraul
Quoted 3 lines · Peter Waechtler
I plan to separate the interfaces and just share the message stuff. But time was getting short. :)
Ok, you plan to rewrite the patch entirely, and what you have posted is a placeholder.
How would the result look like?
I'm thinking about
- real syscalls
- pipefs like filesystem stub, kern-only mounted, not visible for normal fs operations.
- not using the sysv array
Quoted 3 lines
Could you check the sus standard if that is permitted? A child would inherit the mqueue on
fork().
SuSv3:
[MSG] The child process shall have its own copy of the message queue descriptors of the parent. Each of the message descriptors of the child shall refer to the same open message queue description as the corresponding message descriptor of the parent.
Quoted 3 lines
For the locking stuff, the patch should probably depend on the sysv rcu patch, it cleans up locking a bit.
Well, I am a victim of "information hiding" ;-)
msq_lock(id) does not lock a queue, it locks/unlocks the whole array. Forget my post about a deadlock in ipc_addid()
Quoted 9 lines · Peter Waechtler
Quoted 5 lines
For the locking stuff, the patch should probably depend on the sysv rcu patch, it cleans up locking a bit.
Well, I am a victim of "information hiding" ;-)
That's not information hiding - there were 3 different locking implementations: first one with a per-queue spinlock that didn't support growing the number of queues at runtime, then one with a global rw lock and a per-queue spinlock, and the simple, global spinlock version that's part of 2.3.x-2.5.4x.
Quoted 4 lines
msq_lock(id)does not lock a queue, it locks/unlocks the whole array. Forget my post about a deadlock inipc_addid()
Which deadlock did you see? With the RCU ipc patch [part of 2.5.44-mm6], msg_lock again locks the queue, not the whole array. Calls to ipc_addid() with the msq spinlock aquired are not permitted.
--
Manfred