Hello Will,

05.10.99 02:15, Will Honea wrote a message to Vitus Jensen:

VJ>> I'm implementing some DLLs to allow third party applications to
VJ>> control machines via serial lines.  The DLLs use CRT routines
VJ>> (malloc,free) and are currently statically linked to their own
VJ>> version of CRTs. I'm wondering whether those statically linked
VJ>> CRTs are the correct way to do it or may even cause errors (in
VJ>> fact there is currently a hang situation reported).

 WH> Well, static linking is a good way to use LOTS of memory.  Since
 WH> you are using several DLL's you could save a lot of space by
 WH> dynamic linking.  I use it in one big app I work on and the RTL
 WH> (re-named per IBM rules) is bigger than any of the 'functional
 WH> DLL's.

The DLLs are quite simple and don't use much of the CRT.  Filesizes between 50 
and 70 KB with static linking.  And the machine is really oversized for the
job: 128 MB RAM.


VJ>> Could someone explain the use of the subsystem library (compile
VJ>> switch /Rn)  and whether it's use would be better in my case. And
VJ>> please remember that I have a thread hidden inside the DLLs
VJ>> (currently started via _beginthread but /Rn doesn't support it,
VJ>> DosStartThread plus some magic code required?).

 WH> I use _beginthread() liberally.  Most of my threads deal with
 WH> comm links - network and serial - so it only makes sense to spin
 WH> them off that way.  There are some slicker ways to instantiate
 WH> the threads but they all seem to deny me some important tweeking.
 WH>  A couple of the threads I run will need from 28k to 4 meg for
 WH> stack/heap and _beginthread() allows me the flexibility to
 WH> allocate enough that the thread can then commit whatever it
 WH> really needs.  BTW, all these threads are launched from DLL code
 WH> and use semaphores and a message queue for control and
 WH> process-related communications.  

And those DLLs use statically linked full/subsystem CRT?  Or a shared CRT as
DLL?


 WH> Just be VERY careful of where you put your waits and be extra
 WH> meticulous about cleanup on thread exit.  The biggest trap the
 WH> programmers I work with fall into is misuse of shared memory -
 WH> they just can't seem to clean up after themselves.  I think it's
 WH> a carryover from using multiple processes rather than true
 WH> threads.  Just to ease your mind a little, one comm job that gets
 WH> done has been known to run over 100 threads in an iterative
 WH> challenge-reply communications exchange and I've always been able
 WH> to kill the process cleanly at any stage.  

Actually I think memory allocation/cleanup, waiting (or not waiting) for
threads to die is no complicate task.  You have to stop and think sometimes
but, well, you write every line and there is always time to think (or should).

The most complicated in this scenario are the things you don't see.
What happens in _DLL_InitTerm?   With full CRT support you don't really need
to code your one but what has been done by the compiler vendor?  I can tweak
VAC to call DosWaitEventSem(,-1) during the _CRT_Term called in
_DLL_InitTerm...

Another major point are exceptions.  I've learned that I need my own exception 
handlers if I use my own CRT (#pragma handler will do).  But what has to be
done in threads started by _beginthread?  And won't my exception handler
return XCPT_CONTINUE_SEARCH if it doesn't want to handle the exception?  This
will end up in the application's exception handler which has no idea about the 
code which generated the exception...

With /Rn there is no need for exception handlers (as I understand?).


 WH> Also, don't be fooled by the IOC propaganda - the base API's like
 WH> _beginthread()\_endthread() are still quite available.

?IOC?
The compiler tells me that /Gm isn't compatible with /Rn and ignores it.  For
this reason prototypes of _beginthread/_endthread aren't available.  When I
scan cppon30.lib (I think this is the library the compiler links with) then
there the word 'thread' can't be found.
Are you sure that /Rn supports _beginthread?

C-x C-s
    Vitus

--- Sqed/rexx 114:
7102/1