On Mar 7, 2013, at 7:37 PM, George Bosilca wrote:
> An example will be a memory region without a predefined size, that I
> manipulate as opal_list_item_t. This fragment gets allocated when it's size
> is know, then gets OBJ_CONSTRUCT'ed and then used. The reference count is
> playing its role,
On Mar 8, 2013, at 11:55 , Jeff Squyres (jsquyres) wrote:
> On Mar 7, 2013, at 7:37 PM, George Bosilca wrote:
>
>> An example will be a memory region without a predefined size, that I
>> manipulate as opal_list_item_t. This fragment gets allocated when it's size
>> is know, then gets OBJ_CON
I'm sorry Ralph, I'm puzzled by your approach. You knowingly use a broken
example to justify a patch that under correct/consistent usage solve a
non-issue?
Why can't you use any decent memory debugger (fence, purify or valgrind) to
identify the issue you describe below?
George.
On Mar 8, 20
On Mar 8, 2013, at 6:56 AM, George Bosilca wrote:
> Correctly used, OBJ_NEW / OBJ_CONSTRUCT / OBJ_DESTRUCT, are not a bad set of
> macros. When an object is not needed and known not to be refereed anymore, it
> can safely be OBJ_DESTRUCT despite the fact that its reference count is not
> 1. Ot
Isn't that what assert()'s are for? :-)
The point is that for Ralph's case, the #2 assert would cause a notification
*right at the point of the error* (i.e., the errant DESTRUCT). The other tools
you mention all cause notifications long after the DESTRUCT (i.e., when the
freed memory is used,
On Mar 8, 2013, at 15:10 , Jeff Squyres (jsquyres) wrote:
> Isn't that what assert()'s are for? :-)
>
> The point is that for Ralph's case, the #2 assert would cause a notification
> *right at the point of the error* (i.e., the errant DESTRUCT). The other
> tools you mention all cause notif
On Mar 8, 2013, at 9:39 AM, George Bosilca wrote:
> I have a more advanced use case for you. Based on the MPI standard,
> MPI_Finalize can be called while the user still has non-complete requests
> returned by any of the non-blocking calls (there are some drawbacks of
> course, but this is not
On Mar 8, 2013, at 15:56 , "Jeff Squyres (jsquyres)" wrote:
> On Mar 8, 2013, at 9:39 AM, George Bosilca wrote:
>
>> I have a more advanced use case for you. Based on the MPI standard,
>> MPI_Finalize can be called while the user still has non-complete requests
>> returned by any of the non-b
On Mar 8, 2013, at 10:20 AM, George Bosilca wrote:
>> If the app REQUEST_FREE'd a nonblocking send/receive, don't we block in
>> ompi_mpi_finalize() before the call to pml_base_close(), such that the PMLs
>> will be drained before we get to destroying the PMLs?
>
> We don't, as we have no way
It depends. The usage of MPI is valid. Totally weird and absolutely grotesque,
but valid. What is invalid is the access of the array value. There is no
completion call for the irecv and no guarantee for completion on MPI_Finalize,
so making a decision on the content of buf[i] is incorrect.
I th
On Mar 8, 2013, at 10:53 AM, George Bosilca wrote:
> It depends. The usage of MPI is valid. Totally weird and absolutely
> grotesque, but valid. What is invalid is the access of the array value. There
> is no completion call for the irecv and no guarantee for completion on
> MPI_Finalize, so m
On Mar 8, 2013, at 17:37 , "Jeff Squyres (jsquyres)" wrote:
> He removed a bunch of text in the middle (see
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/143). In short: there is
> NO way for a user to know when a REQUEST_FREEd request has completed, because
> *matching* happens in o
On Mar 8, 2013, at 12:07 PM, George Bosilca wrote:
> Check pml_ob1_component.c:230. The commented out test seems to be doing what
> you look for, making sure that when the PML is closed no allocated requests
> are outside of the free list (like the matching or pending queues).
Cool; I'll chec
13 matches
Mail list logo
