Skip to content
Prev 26277 / 63424 Next

CHAR () and Rmpi

Hao Yu,

I spot two types of problematic code. Certainly the memcpy in
conversions.c:54 and 56 will cause problems, but I'm not sure whether
those functions are actually used?

The second paradigm is, e.g., Rmpi.c:561

    MPI_Recv(CHAR(STRING_ELT(sexp_data,i)),
             slen,MPI_CHAR,source,tag, comm[commn],&status[statusn]);

where the first argument to MPI_Recv is a buffer that MPI_Recv will
fill. sexp_data is a user-supplied character vector. A not-clever
solution creates a temporary buffer via R_alloc (for garbage-collected
memory) or R_Calloc (for user-managed memory, probably appropriate in
a loop where you'd like to reuse the buffer), passes the buffer to
MPI_Recv, and then SET_STRING_ELT with the now filled temporary buffer
converted to a CHARSXP with mkChar. I think this is backward
compatible. The user-supplied character vector has gone to waste, used
only to pass in the length of the expected string. mkChar will copy
the temporary buffer (unless an identical CHARSXP already exists), so
that there are potentially three memory allocations per string!  I
suspect most users rely on higher-level access (mpi.par*Apply,
mpi.*.Robj, etc) where this inefficiency is not important or can be
addressed without modifying the public interface.

Martin

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

  
    
Message-ID: <6phtzpdv9gn.fsf@gopher4.fhcrc.org>
In-Reply-To: <Pine.LNX.4.64.0709290655440.19554@gannet.stats.ox.ac.uk> (Brian Ripley's message of "Sat, 29 Sep 2007 07:12:49 +0100 (BST)")