On Feb 18, 2014, at 8:18 AM, George Bosilca wrote:
>> For the longer term (i.e., 1.9), should we add a little opal infrastructure
>> that contains an event base that is run in its own progress thread? This
>> would allow the MPI layer to consolidate into one progress thread (for
>> things tha
On Feb 18, 2014, at 13:16 , Jeff Squyres (jsquyres) wrote:
> Ok, fair enough. My goal was not to spin up another progress thread in my
> BTL, but I can certainly do so (to meet the 1.7.5 timeframe).
>
> For the longer term (i.e., 1.9), should we add a little opal infrastructure
> that contai
Ok, fair enough. My goal was not to spin up another progress thread in my BTL,
but I can certainly do so (to meet the 1.7.5 timeframe).
For the longer term (i.e., 1.9), should we add a little opal infrastructure
that contains an event base that is run in its own progress thread? This would
al
I concur with Brian, you should not expect the runtime to provide a default
event base, especially if you want some level of quality-of-service out of it.
Moreover, with the soon-to-happen move of the BTLs down in OPAL this approach
will definitively not be suitable.
George.
On Feb 18, 2014
And what will you do for RTE components that aren't ORTE? This really isn't a
feature of a run-time, so it doesn't seem like it should be part of the RTE
interface...
Brian
On Feb 17, 2014, at 3:03 PM, Jeff Squyres (jsquyres) wrote:
> WHAT: New OMPI_RTE_EVENT_BASE define
>
> WHY: The usnic
WHAT: New OMPI_RTE_EVENT_BASE define
WHY: The usnic BTL needs to run some events asynchronously; the ORTE event base
already exists and is running asynchronously in MPI processes
WHERE: in ompi/mca/rte/rte.h and rte_orte.h
TIMEOUT: COB Friday, 21 Feb 2014
MORE DETAIL:
The WHY line described i
