Brian Barrett b5b6f4c4bf Remove check for epoch on the receiver side, as this is a race condition between message arrival, and because we'll be still blocking in a synchronization call, is of no consequence to the user. We do an epoch check on the sending side, ...

so this isn't an issue there either.  Refs trac:488

This commit was SVN r12675.

The following Trac tickets were found above:
  Ticket 488 --> https://svn.open-mpi.org/trac/ompi/ticket/488

2006-11-27 22:15:34 +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

Use the MX infinite timeout by default. The user can modify it using an MCA

2006-11-27 20:18:58 +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 for issue IU is seeing on BigRed with connections timing out during

2006-11-27 20:10:27 +00:00

osc

Remove check for epoch on the receiver side, as this is a race condition between message arrival, and because we'll be still blocking in a synchronization call, is of no consequence to the user. We do an epoch check on the sending side,

2006-11-27 22:15:34 +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