margo pool size and noop ults (#6) · Issues · sds / margo

margo pool size and noop ults

In #5 (closed) @carns put in support for margo playing nicely in a "single thread" context (RPC runners in the same physical thread as margo progress). Here's the relevant code:

ABT_pool_get_total_size(mid->progress_pool, &size);
if(size > 0)
{
    HG_Progress(mid->hg_class, mid->hg_context, 0);
    ABT_thread_yield();
}
else
{
    HG_Progress(mid->hg_class, mid->hg_context, 100);
}

Can't remember now, but there was at least some conversation about whether the size > 0 check is the "right" one to make. The server example program would imply that it's not - the pool size is always >= 1 due to the main thread being in the same pool as the one given to margo (causing the thread to revert to strictly polling). However, in my leveldb-hgbots example program, I create a new (empty) pool and thread for the program to run on, sleeping the main thread. Behavior there is as expected.

So how do we reconcile these two configurations? Does it suffice to add a parameter to margo_init indicating that there will be a ULT waiting on completion that it can safely ignore?

In #5 @carns put in support for margo playing nicely in a "single thread" context (RPC runners in the same physical thread as margo progress). Here's the relevant code:

```c
ABT_pool_get_total_size(mid->progress_pool, &size);
if(size > 0)
{
    HG_Progress(mid->hg_class, mid->hg_context, 0);
    ABT_thread_yield();
}
else
{
    HG_Progress(mid->hg_class, mid->hg_context, 100);
}
```

Can't remember now, but there was at least some conversation about whether the `size > 0` check is the "right" one to make. The server example program would imply that it's not - the pool size is always `>= 1` due to the main thread being in the same pool as the one given to margo (causing the thread to revert to strictly polling). However, in my leveldb-hgbots example program, I create a new (empty) pool and thread for the program to run on, sleeping the main thread. Behavior there is as expected.

So how do we reconcile these two configurations? Does it suffice to add a parameter to `margo_init` indicating that there will be a ULT waiting on completion that it can safely ignore?