George Bosilca 658879232b Several small improvements: ...

- consistent error message when something fails (via BTL_ERROR macro)
- decrease the number of jumps.
- cleanup some parts of the code.

This commit was SVN r12719.

2006-12-01 21:48:06 +00:00

..

allocator

Adjust allocation size to be a quantity divisible by sizeof(size_t). This

2006-10-25 18:22:38 +00:00

bml

more fixes for failover.. and yet still more to come..

2006-11-06 21:27:17 +00:00

btl

Several small improvements:

2006-12-01 21:48:06 +00:00

coll

Bring over the update to terminate orteds that are generated by a dynamic spawn such as comm_spawn. This introduces the concept of a job "family" - i.e., jobs that have a parent/child relationship. Comm_spawn'ed jobs have a parent (the one that spawned them). We track that relationship throughout the lineage - i.e., if a comm_spawned job in turn calls comm_spawn, then it has a parent (the one that spawned it) and a "root" job (the original job that started things).

2006-11-14 19:34:59 +00:00

common

Move it in the right place.

2006-08-21 04:05:19 +00:00

io

Fixes trac:529.

2006-10-27 12:32:36 +00:00

mpool

Last set of explicit conversions. We are now close to the zero warnings on

2006-10-20 03:57:44 +00:00

mtl

Fix slow startup issue with the MX MTL. The problem is caused by mx_connect() being a one-sided operation from the API level, but not being an interrupting call when the target is not entering the MX library. So if most of the processes exit mtl_mx_add_procs() and enter the stage gate 2 barrier, the other processes can only progress their mx_connect() calls when the targets enter the mx library. Because the event library is in EV_ONELOOP mode, this only happens once a second. The mx progress thread (hidden in the MX library) also only wakes up once a second, so mx_connect calls can take a second to complete.

2006-12-01 02:49:01 +00:00

osc

* silence compiler warning

2006-12-01 20:01:53 +00:00

pml

Bring over the update to terminate orteds that are generated by a dynamic spawn such as comm_spawn. This introduces the concept of a job "family" - i.e., jobs that have a parent/child relationship. Comm_spawn'ed jobs have a parent (the one that spawned them). We track that relationship throughout the lineage - i.e., if a comm_spawned job in turn calls comm_spawn, then it has a parent (the one that spawned it) and a "root" job (the original job that started things).

2006-11-14 19:34:59 +00:00

rcache

Correctly determine the first element on the list. opal_list_get_prev() never

2006-11-01 13:44:47 +00:00

topo

The last patch for Windows support. Mostly casting and conversion to C++ friendly headers.

2006-08-24 16:38:08 +00:00

win_makefile

Update the copyright notices for IU and UTK.

2005-11-05 19:57:48 +00:00