There are some places inside the QNET, a thread wake up for an
internal event, we need to “pick a priority” for these thread.
For example, the timer pulse. When timer goes off, a pulse fired, thread
will adjust to the pulse priority, but which priority it should be?
Most of other code, (stack, io-net) are fixed for allow user to specify
the priority of this kind of “internal event priority”, from command line
The 6.2.1 QNET happened to choose “base priority”, which basiclly
is the priority it get initialized, as this internal priority. By raising
priority, the io-net thread who handle the mount request inherit that
priority, and load/initialize QNET with that priority.
I won’t call this behavior a bug, but agree a command line option
(to adjust this priority) would be more obverious to users.
John Nagle <firstname.lastname@example.org> wrote in message
Bill Caroselli wrote:
John Nagle <> email@example.com> > wrote:
JN > Xiaodan Tang wrote:
When you “mount -Tio-net npm-qnet.so”, try raise the priorities line
“on -p 16 mount -Tio-net npm-qnet.so”, and see if that helps you?
JN > That works. Thanks. With that mount at priority 16,
JN > GUI activity no longer stalls QNET. I’m not missing a
JN > single time-critical response now, no matter what I do at user
JN > level.
Please explain why the priority of the mount command has an effect on
priority that io-net runs QNET at?
Presumably the mount command is starting the threads that
actually do the work, and so they inherit the priority of the
Someone with access to the source code should answer this one.
It’s not clear whether it should happen this way or whether it’s
a bug. But it’s real.