This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Yes and no. It will consume memory as the message will enter the proc's OOB
and just sit there. However, it will be released when the proc finalizes the
If that would be a problem, it would be pretty easy to add a directive to
"delete this message if a recv isn't already waiting for it".
Alternatively, you could just have a non-blocking recv sitting on each proc,
have it check to see "is this of interest to me", and release the message
memory that way. Might have to add the list of intended proc names to the
front of the message so each proc could decide whether or not to pay
attention to it...
On 1/29/08 12:37 PM, "Richard Graham" <rlgraham_at_[hidden]> wrote:
> Sounds like xcast will do what I need.
> If I don't pull data on all the procs, only the ones calling the recv, will
> I basically create a memory leak ?
> On 1/29/08 2:27 PM, "Ralph H Castain" <rhc_at_[hidden]> wrote:
>> Depends upon which one you are using. For example, allgather operates across
>> the entire job, so all procs in that jobid have to invoke it. On the other
>> hand, allgather_list only operates across the procs specified in the list,
>> so only they need to invoke it.
>> Xcast sends a message to all procs in the job, but none of those procs needs
>> to invoke anything - we just deliver the message to the specified RML tag on
>> each proc. Of course, we assume that there is a recv (typically
>> non-blocking) posted on that tag (or that it will be posted eventually). If
>> not, then the message will just sit in the local oob waiting to be delivered
>> - no harm done, it just gets ignored.
>> Hope that helps. Let me know if you need some variant as I am adding (not
>> reducing or changing) grpcomm capabilities on the tmp branch.
>> On 1/29/08 12:19 PM, "Richard Graham" <rlgraham_at_[hidden]> wrote:
>>> Are the group operations in ORTE (I assume this is what the grpcomm
>>> component does) available to subsets of a job, or do all procs in the
>>> orte_jobid_t need to invoke this ?
>>> devel mailing list
>> devel mailing list
> devel mailing list