If your timer is actually generating an interrupt to the process, then
that could be the source of the problem. I believe the event library
also treats interrupts as events, and assigns them the highest
priority. So every one of your interrupts would cause the event
library to stop what it
Jeff & George,
> Hum; interesting. I can't think of any reason why that would be a
problem offhand. The
> mca_btl_sm_component_progress() function is the shared memory
progression function.
> opal_progress() and mca_bml_r2_progress() are likely mainly
dispatching off to this
> function
There might be one reason to slowdown the application quite a bit. If
the fact that you're using timer interact with the libevent (the
library we're using to internally manage any kind of events), then we
might end-up in the situation where we call the poll for every
iteration in the event
On Jan 9, 2009, at 12:39 AM, William Hachfeld wrote:
Can any of the OpenMPI developers speculate as to possible
mechanisms by which the ptrace() attachment , signal handler, or
timer registration and corresponding signal delivery could cause
large amounts of time to be spent within the "pro
