Maybe my 2 cents comes too late: it’s an old, potentially dead thread and also
QNX4 is almost potentially dead (even if the latter one is really an
overstatement, at least from a non-marketing-based point of view).
But, at least it can worth to correct some sentences of the
homage/tribute-script planned for tombstone of QNX4 (oops, an overstatement
again)…
Previously, David Gibbs wrote in qdn.public.qnx4:
Marty Doane <doanemr@remove_rapistan.com> wrote:
Does Proc32 handle messages while it’s doing this housecleaning?
I think so, but I’m not positive.
I don’t think so, and I’m absolutely negative. (At least our earlier test
results press me to be negative regarding this issue).
If not, what system calls produce messages to Proc32?
In general, if you are asking for an operating system resource to be
allocated or configured on your behalf, that will involve a sending a
message to Proc32. (Well, and freeing many such resources too.)
These are generally setup/initialization type behaviour, rather than
ongoing run-behaviour.
(To Marty:) Take a look at /usr/include/sys/proc_msg.h…
There must be a stress on word ‘generally’ here: even a clock_gettime() (and
others equivalents for getting a timestamp-related info) will lead to
msg-passing with Proc32 (->_PROC_TIME msg). Maybe this is a worth-to-mention
exception: generally we would not classify this operation, as a
‘setup/initialization type behaviour’ (yes, this is an understatement)…
[On the other hand, yes, we have qnx_osinfo()'s undocumented shared ‘timesel’
to fight against the mentioned exception, but that’s a non-standard hack for a
very specific issue only…]
Just raising my process’
priority won’t help if it ends up send-blocked on proc.
Right. (And not only theoretically right, it really happens under QNX4:
Proc32 will not reply, while it is performing the memory cleanup; at least
‘monitor’ dumps will show that…)
Gyorgy Tamasi (gtamasi@freemail.hu)