George Bosilca c8222b57eb The Windows PLS now is able to spawn process locally. ...

This commit was SVN r13074.

2007-01-11 00:16:58 +00:00

..

base

Repair support for Bproc 4 on 64-bit systems. Update the SMR framework to actually support the begin_monitoring API. Implement the get/set_node_state APIs.

2006-12-15 02:34:14 +00:00

bproc

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

cnos

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

gridengine

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

poe

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

process

The Windows PLS now is able to spawn process locally.

2007-01-11 00:16:58 +00:00

proxy

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

rsh

Need to include strings.h because that is where the rindex()

2007-01-10 18:44:08 +00:00

slurm

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

tm

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

xcpu

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

xgrid

Remove unneeded PARAM_INIT_FILE variable in configure.params files used by

2007-01-08 03:44:22 +00:00

Makefile.am

Here is the major MAD-cure commit. I have written plenty about it, so I refer you here to those messages for a description of everything that was done.

2006-09-14 21:29:51 +00:00

pls_types.h

Here is the major MAD-cure commit. I have written plenty about it, so I refer you here to those messages for a description of everything that was done.

2006-09-14 21:29:51 +00:00

pls.h

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