Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!sdd.hp.com!hp-pcd!hplabs!hplextra!hplb!gw
From: gw@hplb.hpl.hp.com (Gunther Walther)
Subject: Re: [VW] DLL and C Connect - can it be asynchronous?
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
Message-ID: <DoB6G5.Bz7@hplb.hpl.hp.com>
Date: Fri, 15 Mar 1996 12:24:04 GMT
References: <4i8sco$bjs@ubszh.fh.zh.ubs.com>
Nntp-Posting-Host: gwalther.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Bristol, England
X-Newsreader: TIN [version 1.2 PL0.7]
Lines: 97

In article <4i8sco$bjs@ubszh.fh.zh.ubs.com> you wrote:
: we need to connect from Visual Works 2.5 to a library/C program on unix which
: queries a database on a different machine via DCE. The access pattern is
: simple: We ask a question and an answer is returned to us. We have the VW DLL
: and C Connect package.

: The question we have is whether this call to the library/C program can be
: asynchronous. What I mean is that if we call a C routine from a Smalltalk
: process and the processing takes some time on the C side, is control switched
: to another Smalltalk process in the mean time (because the first call is
: wrapped with a promise, for example) OR does the Smalltalk image 'hang' while
: the C side is processing?

It blocks, no smalltalk while in C, except in call-backs..

: Ideally, we also need a timeout for the C call.

Not that I know of, unless you do it in your C call yourself. I'm not sure
whether I would dare to use any unix signals.

: Is there a general asynchronous solution somewhere posted in the archives I
: have overlooked?Something which came close is the 'managing asynchronous
: network messages FROM external application from the STReport Sept 95 / the
: ExternalReadStreamAdaptor.st file. Correct me if I'm wrong, but this is more if
: I want to receive asynchronous messages. Furthermore, I would rather calla C
: library directly and modify C data objects instead of having to encode messages
: into ASCII strings and having to interpret them on the C side, again.

From your description above, you already have a good reference on this topic.
In case you are doing RPC, the only things ST has to understand are the
message boundaries and the request response pairs in the stream.

The simple approach here suffers from blocking in C:
ST --> DB interface --> DCE --> network
   <-- DB interface <-- DCE<--

The approach here blocks in ST in a high priority process, so it wakes up
as soon as there is data:

ST application --> DB interface --> DCE --> ST application
    --> ST sends DCE message in high priority process. (ST application and ST high priority process block)
    --> ST high priority process receives matching response or times out --> ST application --> DCE --> ...

When you have your message isolated, you pass the byte array to C and have
the C function decode it.  There is no need to have an ASCII interface
between ST and C. Passing byte arrays between ST and C is fairly efficient.
You can access C structure fields in ST almost as you would access a
dictionary.


When it comes to performance, it all depends a bit on:

	- how complex your C decoder is
	- what kind of interaction with C is needed from your ST
	  application and on what level.
	- how long your messages are
	- what frequency they arrive
	- whether you are building a prototype or final application.
	- does the decoder already exist?
	- do you want to use the C decoder in a non ST product as well?
	- how are decoding errors handled in the decoder?
	- how would you like to handle networking errors and reconnections.
	- what type the decoded fields are (integers with <27 bit are easier
	  to handle if you choose to create ST objects from C).
	- what performance you need.
	- how you like to manage the memory on the C heap.
	- whether you have the source code for the C decoder.
	- experiments to validate your choosen approach...

It is also possible to decode the messages fully in ST. This might work
quite well, as long as you do not need any bit manipulations. I guess
as you are in a bank, security and encryption is an issue and this is
associated with a lot of bit manipulations.

If you go with a C decoder (is there any DCE implementation in ST?),
interfacing the decoder in a way that it gets a pointer to the data and
length as an input parameters seems to be a safe bet. Idealy it should
return a length and a pointer to the decoded/encoded message that can be
passed to your DB interface. Interfacing this then to the network is a minor
issue.

I hope this helps,

gunther

PS: However, there is also the good old select() call. You are free to
    do everything in C and just make sure it never blocks. You then need to poll
    C in regular intervals from ST. You receive messages in C and decode them
    in C. Your C code could return either NULL or a pointer to the latest
    decoded structure. 

--
------------------------------------------------------------------
Gunther Walther                 | Phone: +44 117 9228518 (direct)
Hewlett-Packard Laboratories,   |    or: +44 117 9799910 x28518  
Filton Road, Stoke Gifford,     | FAX:   +44 117 9228972
Bristol, BS12 6QZ, U.K.         | EMAIL: gw@hplb.hpl.hp.com
