Conference turris::languages

1. I've never seen callable services do that before, except for the LIB$GET_VM/
   LIB$FREE_VM type ones.  It's usually considered friendlier to let the user
   allocate the buffer themselves unless...

2. If it's a string, why don't you use string descriptors and STR$COPY_DX?
   That way if the user wants to manage the buffer, they can, but if they
   don't want to, they can use a dynamic descriptor and let the STR$ stuff
   take care of it all for them.  (This also makes it very friendly if you
   have people programming in BASIC or any other language which uses dynamic
   descriptors "liberally".)

3. This belongs in the CLT::RTL conference, I believe, as it's not a language
   issue, but rather pertaining to the VMS calling standard.

4. It should work, but make sure your SDL definitions are right.  I think
   it would read...

ENTRY FOO$MUMBLE
   PARAMETER (
      ADDRESS(CHARACTER *) OUT NAMED PARAM_NAME);

   But then I'm no SDL whiz.  SDL will keep the users honest if they're
using a reasonably-strongly typed language.


						-mjg

Languages without a pointer type (eg. FORTRAN, COBOL) will have problems
with your interface.  As mentioned in .1, it is better to let the caller
allocate the space if that is possible.

I have another question.  If your routine returns a pointer, who is responsible
for freeing the memory block that the pointer points to and what routine
should be used to free the memory.  (If it is allocated with a Pascal NEW
then it must be released with a Pascal DISPOSE; if it is allocated by
LIB$GET_VM then it must be freed with LIB$FREE_VM; if it is allocated
by STR$xxx then it will probably have to be freed with STR$FREExxx).
If you provide this return by pointer interface then you should also
provide another entry point to free the memory referenced by the pointer.

RE .2

The memory block would be freed by the layer which allocated it. The would
implicitly happen the next time the application called the receive routine. If
the application wanted to retain the memory, then it would make a copy of it.

The problem I am trying to solve is to minimize the number of data copies
required. The product I am designing is a callable interface library which
allows DEC applications to communicate with devices in an SNA environment by
communicating through a DECnet/SNA gateway. Within the callable layer there will
always be one or more hot reads on a DECnet logical link. The callable layer
will hold on to received messages until the application requests them. Ideally I
want the same buffer used to receive the data on the logical link to be passed
to the application, hence my reason for wanting to pass a pointer up to the
application.

Another suggestion I received was to use dynamic string descriptors. Do our
languages have an easier time with descriptors? I have been staying away from
descriptors because they might not port well to a unix environment.

> The memory block would be freed by the layer which allocated it. The would
> implicitly happen the next time the application called the receive routine. If
> the application wanted to retain the memory, then it would make a copy of it.
    
    And what happens after the last call the user makes to the receive
    routine, when the application the user is writing turns to doing other
    things than SNA for a few hours?  The theory of the thing is that every
    byte of allocated memory should be able to be returned by a means other
    than image run-down.  By and large, most VMS layered products are good
    about  this, and not having this behavior is universally regarded as a
    bug.  This is becoming especially important in a workstation world
    where tens of applications may run without image run-down for weeks at
    a time.  (I generally keep Notes and DECwrite around, even though I
    only use them sporadically.)
    
    								Ralph

RE .4

One of the interface calls is to terminate a session, not the image. Session
termination would clean up all memory associated with that session. To relate
this to your example of leaving notes running, you can leave it running with
a conference open or with no open conferences. If you have an open conference
then notes is typically holding on to extra memory (i.e. the current note being
read). If you the close the conference your "session" to that conference is
terminated and memory associated with it is freed up.

If the application wanted to keep the session up, but also free the last 
received buffer without posting another receive, my proposed interface does not
provide for that.

>The problem I am trying to solve is to minimize the number of data copies
>required.

  In languages with no pointer indirection facilities (like COBOL and FORTRAN),
  the most likely thing a programmer will do with the pointer is copy the
  block to a local storage area for use.  The only way around this in COBOL
  is to do some hacking like passing the value returned to a subroutine written
  in some other language to do the indirection.  So you won't have avoided
  the copy in two popular languages, and you've pushed the responsibility
  for doing the copy onto your users.  

  Why don't you try working out program examples in some different languages?
  You may find out quite a bit for a small investment in time.

  Craig 

>The problem I am trying to solve is to minimize the number of data copies
>required.

   A noble cause, to be sure, but it is worth the bother?  How much data
are you talking about?  a few (hundred) bytes?  100K bytes?  1meg+?
I'd venture to guess that unless you're talking about the 100K+ scenerio,
it's probably not worth it.

   Not to mention - why would this cause multiple copies to be hanging around?
We need to know more about your application, but if the user hands you a buffer
and says, "here's an address, feel free to write to the next 1/2 megabyte..."
where the extra copy?  Even if you accept it into an internal buffer of
some kind (internal to your layer), you free that buffer after copying the
data into the users' space anyways, right?

   I could (personally) only see this being a real concern if you're talking
about monolithic chunks of data, in the one megabyte+ range, which you
couldn't decompose into smaller chunks which were requested as needed.

					-mjg

Thank you all for your replies. As I suspected, my proposed interface of passing
back pointers does not map too well into all languages. 

Mike

   I think it's a style issue, not just a language issue.

   If you're going to give the user some stream of data, you should let them
choose where it goes.  If you want to pass around pointers to internal
data structures, you're much better off calling them "contexts" or some such
and making them opaque types, and then providing services to copy the data
out of them into the user-specified areas and to release them.  (A reasonable
recent example here is DECwindows compound strings...)

   (BTW "user" here means "user of your routines", and "internal" means
within your module/whatever)

   It just doesn't sit well with me... (or maybe it's just all the coffee I've
had lately... ;-)


					-mjg