This is what I would have expected, at least on any systems where
MUMPS jobs are implemented as native threads or processes, but not
that many years ago, I've heard that people have reported finding
otherwise. But be that as it may, yielding the processor isn't the
only issue. You still don't want to "wake up" and perform an (albeit
global) I/O operation every second. I/O is still expensive, and not
yielding control of the processor (as was an issue in older Windows
and even Java implementations) isn't the only issue here.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The policy of being too cautious is
the greatest risk of all."
--Jawaharlal Nehru
On Jul 29, 2005, at 7:08 PM, Jim Self wrote:
This is a non-issue in MUMPS implementations that I have worked
with in recent years, even
a HANG of only one second in such a loop is sufficient to prevent
it from consuming
significant processing time while idle.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
