Issue 863: Read-only restrictions on parameters (cxx_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: A variable-length in parameter is read-only in the server, and a variable-length out parameter or return value is read-only in the client. I believe the restriction is too harsh to be useful, and the optimization permitted by the restriction is not worth it. Resolution: Clarifying text added, fixed Revised Text: Lift the restriction. No ORB that we are aware of makes use of the possible optimizations, and the restriction places unnecessary burdens on application developers. Revised Text: On page 20-109 of ptc/98-09-03, delete starting from paragraph beginning with: The ORB is permitted to allocate a single contiguous area of storage for all data associated with a variable-length parameter. This permits an ORB to, for example, unmarshal a sequence of... Delete all text up to and including the paragraph ending with: ... but calling delete on a pointer to const object is an error. A compliant mapping implementation therefore is not required to detect this error. Also delete footnote 17. Actions taken: Actions taken: January 5, 1998: received issue February 19, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 5 Jan 1998 14:20:20 +1000 (EST) From: Michi Henning To: cxx_revision@omg.org Subject: Read-only restrictions on parameters Hi, the spec currently mandates that caller-allocated memory is read-only for the callee, and that callee-allocated memory is read-only for the caller. To put it differently, a variable-length in parameter is read-only in the server, and a variable-length out parameter or return value is read-only in the client. The reason for the restriction is to permit an ORB to allocate memory for a variable-length value in a single allocation. For example, memory for a sequence of strings can be allocated by allocating memory for the sequence class plus the total number of bytes required to hold all strings in a single call to the allocator (thanks to Steve Vinoski for pointing this out). This saves calls to the memory allocator, but now requires the sequence to be read-only, because individual strings in the sequence can no longer be deallocated. I believe the restriction is too harsh to be useful, and the optimization permitted by the restriction is not worth it. Consider: The allocation optimization for variable-length parameters only applies if the call is remote (for the co-located case, the appropriate class instance is passed by reference or by pointer directly). The savings in run-time overhead are minimal (and probably immeasurably small) compared to the delays incurred by going over the wire. In other words, the optimization doesn't really optimize anything. In addition, even assuming the optimization is worthwhile, it will be defeated by the application code: if the application code wants to modify a received variable-length value, it must first make a copy of the value and then modify the copy. In other words, the calls to the memory allocator that are saved by the marshaling code are simply delayed until the application ends up making them later anyway. The net gain is zero in the case of parameters that are modified. I would suggest to drop the read-only restriction since it leads to a very subtle source of latent bugs - not adhering to it will go undetected in every ORB I am aware of, but means that application developers can unwittingly write non-compliant code. Dropping the restriction would avoid this potential problem and also lead to a simpler and more coherent mapping. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@biggar.org Date: Sun, 04 Jan 1998 22:38:22 -0800 From: Jonathan Biggar To: Michi Henning CC: cxx_revision@omg.org Subject: Re: Read-only restrictions on parameters References: Michi Henning wrote: > Hi, > > the spec currently mandates that caller-allocated memory is read-only > for the callee, and that callee-allocated memory is read-only for the caller. > > I believe the restriction is too harsh to be useful, and the optimization > permitted by the restriction is not worth it. > > Consider: The allocation optimization for variable-length parameters only > applies if the call is remote (for the co-located case, the appropriate > class instance is passed by reference or by pointer directly). The > savings in run-time overhead are minimal (and probably immeasurably small) > compared to the delays incurred by going over the wire. In other words, > the optimization doesn't really optimize anything. > > In addition, even assuming the optimization is worthwhile, it will be > defeated by the application code: if the application code wants to modify > a received variable-length value, it must first make a copy of the value > and then modify the copy. In other words, the calls to the memory > allocator that are saved by the marshaling code are simply delayed until > the application ends up making them later anyway. The net gain is zero > in the case of parameters that are modified. Actually, there is another optimization that can be involved here, especially if in parameters are read-only for servers. In many cases, and in particular for strings, the ORB can optimize by passing in a pointer to the marshalled data in the request/response directly, and avoid doing any memory allocation at all beyond allocating the buffer for the incoming message. I haven't thought about all of the circumstances, but there may be cases where allowing the programmer to scribble in the marshal buffer could cause problems. Jon Biggar jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 5 Jan 1998 16:55:49 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: cxx_revision@omg.org Subject: Re: Read-only restrictions on parameters On Sun, 4 Jan 1998, Jonathan Biggar wrote: > Actually, there is another optimization that can be involved here, especially if > in parameters are read-only for servers. In many cases, and in particular for > strings, the ORB can > optimize by passing in a pointer to the marshalled data in the request/response > directly, > and avoid doing any memory allocation at all beyond allocating the buffer for the > incoming > message. I haven't thought about all of the circumstances, but there may be > cases where > allowing the programmer to scribble in the marshal buffer could cause problems. I don't think this causes a problem though. Variable length in parameters are already passed to the server by const reference, so the read-only nature is enforced. For out parameters and return values, I think changing the value would prevent the optimization you describe though. For example, changing a single string inside a sequence of strings would require deallocation of a string in the middle of a marshaling buffer, which won't work. The alternative would be to carry an additional flag for each sequence element to keep track of whether deallocation for that element is required, which isn't pretty. But is this optimization actually important in the sense of "is there any ORB that uses it"?. If not, it probably is not worth preserving. I'm more worried about the fact that programmers will unwittingly commit grave sins by modifying values that are meant to be read-only, only to find out about their mistake the hard way, when either their ORB's implementation changes, or when the code needs to be ported to a different ORB. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: vinoski@207.60.244.2 Date: Mon, 05 Jan 1998 09:44:08 -0500 To: Michi Henning From: Steve Vinoski Subject: Re: Read-only restrictions on parameters Cc: cxx_revision@omg.org References: <34B07FDE.EE0FEB0D@biggar.org> At 04:55 PM 1/5/98 +1000, Michi Henning wrote: >> Actually, there is another optimization that can be involved here, especially if >> in parameters are read-only for servers. [snip] > >I don't think this causes a problem though. Variable length in >> parameters >are already passed to the server by const reference, so the read-only >nature is enforced. For out parameters and return values, I think changing >the value would prevent the optimization you describe though. Originally we wanted to be able to enforce the const nature of "out" parameters just like that of "in" parameters by somehow including const in the "out" parameter type. Something like: // IDL interface A { void op(out string s); } // C++ void A::op(const char*& s); The caller would pass a reference to a pointer to const char, and the ORB would fill the pointer in. This would allow the caller to access but not modify the "out" string. Unfortunately, when we put the mapping together back in 1993, calling delete on a pointer to const was illegal in C++. We therefore decided to keep the approach but not use the const. The ANSI/ISO committees have since lifted the restriction, but it's much too late now to make this sort of change, since it would affect almost every CORBA C++ program. Similarly, the pointers passed to the Any operator>>= should have also been typed as references to pointers to const. Since the caller doesn't delete those items, it would have worked fine, even back in 1993. Unfortunately, it was overlooked, and it's probably too late to change this as well. (This one is totally my fault.) >But is this optimization actually important in the sense of "is there >any ORB that uses it"?. If not, it probably is not worth preserving. >I'm more worried about the fact that programmers will unwittingly commit >grave sins by modifying values that are meant to be read-only, only >to find out about their mistake the hard way, when either their ORB's >implementation changes, or when the code needs to be ported to a different ORB. As it stands now, I doubt that programmers even follow this restriction because it can only be enforced by words in the spec. Restrictions that can't be enforced by the C++ compiler or by the ORB runtime are of little use. I'd also like to hear from other C++ mapping implementors: does anyone actually make use of this restriction for optimization purposes? Since the current C++ RTF ends on January 19th and doesn't have the charter to make these kinds of changes, I'm going to suggest that the new C++ RTF to be created at the Salt Lake City meeting next month have a little more freedom. Hopefully that will allow nagging issues like this one to be properly addressed. --steve Date: Mon, 15 Feb 1999 10:55:19 +1000 (EST) From: Michi Henning Reply-To: cxx_revision@omg.org To: cxx_revision@omg.org Subject: Proposal for 863 Organization: Triodia Technologies The read-only restrictions on variable-length return values and out parameters means that the following code is illegal: // IDL interface Foo { string get_name(); void modify_name(inout string name); }; // C++ Foo_var fv = ...; CORBA::String_var name = fv->get_name(); fv->modify_name(name); The read-only restriction is awkward in the extreme, especially since there is no way to detect the error at compile time and all current ORB implementations behave correctly for this code. To fix this, delete the text dealing with read-only restriction on pages 20-76 and 20-77: Delete para beginning with: The ORB is permitted to allocate a single contiguous area of storage for all data associated with a variable-length parameter. This permits an ORB to, for example, unmarshal a sequence of... Delete all text up to and including the para ending with: ... but calling delete on a pointer to const object is an error. A compliant mapping implementation therefore is not required to detect this error. Delete footnote 15 referenced from the last para. Cheers, michi. Copyright 1999 Michi Henning. All rights reserved. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html