path: root/FAQ

There are many changes and improvements in the new version of ACE.
The ChangeLog file contains complete details about all of them.

I've tested ACE thoroughly on Solaris 2.3 and 2.4 with the SunC++ 4.x
compiler and Centerline 2.x.  I've also tested it with the SunC++ 3.x
compiler on the SunOS 4.x platform.  However, I've not been able to
test it on other platforms.  If anyone has time to do that, and can
report the results back to me I'd appreciate that.

Please let me know if you have any questions or comments.

	Doug

----------------------------------------

1. SIGHUP

> 1) Where the heck does the HUP signal get registered for the 
> $ACE_ROOT/tests/Service_Configurator/server stuff? I looked there and
> in $ACE_ROOT/libsrc/Service_Configurator. No luck. I guess I am
> just blind from reading.

	Take a look in ./libsrc/Service_Configurator/Service_Config.h.
The constructor for Service_Config is where it happens:

  Service_Config (int ignore_defaults = 0, 
		  size_t size = Service_Config::MAX_SERVICES, 
		  int signum = SIGHUP);

----------------------------------------
2. Multi-threaded Signal_Handler support

> It appears Signal_Handler is
> not setup for multi-threaded apps.  How do you handle signals
> in different threads? Do I have to put in the hooks in my app or should
> it go in the Threads arena?

	Ah, good question...  My design follows the approach espoused
by Sun.  Basically, they suggest that you implement per-thread signal
handling atop of the basic UNIX signal handlers (or in the case of
ACE, the handle_signal() callbacks on Event_Handler subclasses) by
using the thread id returned by thr_self() to index into a search
structure containing the handlers.  This should be pretty straight
forward to layer atop the existing ACE Signal_Handler mechanisms.
However, you might ask yourself whether you really want (1) separate
signal handler *functionality* in different threads or (2) different
threads that mask out certain signals.  The latter might be easier to
implement and reason about!

----------------------------------------
3. Problems compiling ACE with G++

> I substituted -lg++ for -lC in macro_wrappers.GNU and ran make.
> 
> Most stuff seemed to build.  Continually got messages like the following:
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libASX.a: warning: archive has no table of c
> ontents; add one using ranlib(1)
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libThreads.a: warning: archive has no table 
> of contents; add one using ranlib(1)
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libSPIPE.a: warning: archive has no table of
>  contents; add one using ranlib(1)
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libASX.a: warning: archive has no table of c
> ontents; add one using ranlib(1)
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libThreads.a: warning: archive has no table 
> of contents; add one using ranlib(1)
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libSPIPE.a: warning: archive has no table of
>  contents; add one using ranlib(1)

> no matter how many times I used ranlib or removed the libraries and re-compiled
> or whatever.  Perhaps these are System V specific and will not work on 4.1.3?

	Yes, that's exactly right.  If you look at the files, they all
contain ifdef's for features that aren't included in the
./include/makeinclude/wrapper_macros.GNU file.  To make this more
obvious, I've enclosed the following message in the ACE-INSTALL.html file:

	* Sun OS 4.1.x

		  Note that on SunOS 4.x you may get warnings from the 
		  linker that "archive has no table of contents; add
		  one using ranlib(1)" for certain libraries (e.g.,
		  libASX.a, libThreads.a, and libSPIPE.a).  This 
		  occurs since SunOS 4.x does not support these features.

> never able to get .so -- assume these are shared libraries that gcc can not
> deal with.

	Yes, if you use the stock gcc/gas/gnu ld
compiler/assembler/linker, you won't get shared libraries to work.  It
is possible to hack this by using the "collect" version of g++.
However, as usual, I strongly advise people to stay away from g++ if
you want to use shared libraries or templates.

> got some linker errors as follows:
> 
> g++ -g  -DACE_NTRACE  -DACE_HAS_MT_SAFE_SOCKETS -DACE_HAS_NO_T_ERRNO -DACE_HAS_
> OLD_MALLOC -DACE_HAS_POLL -DACE_HAS_SEMUN -DACE_HAS_SETOWN -DACE_HAS_STRBUF_T -
> DACE_HAS_STREAMS -DACE_HAS_SVR4_DYNAMIC_LINKING -DACE_HAS_TIUSER_H -DACE_HAS_SY
> S_FILIO_H -DACE_PAGE_SIZE=4096 -DACE_HAS_ALLOCA -DACE_HAS_CPLUSPLUS_HEADERS -DA
> CE_HAS_SVR4_SIGNAL_T -DACE_HAS_STRERROR -DMALLOC_STATS -I/usr2/tss/jvm/ACE_wrap
> pers/include  -I/usr2/tss/jvm/ACE_wrappers/libsrc/Shared_Malloc  -o test_malloc
>  .obj/test_malloc.o -L/usr2/tss/jvm/ACE_wrappers/lib  -Bstatic -lSemaphores -lS
> hared_Malloc -lShared_Memory -lReactor -lThreads -lMem_Map -lLog_Msg -lFIFO -lI
> PC_SAP -lMisc -lnsl -lg++
> ld: /usr2/tss/jvm/ACE_wrappers/lib/libThreads.a: warning: archive has no table 
> of contents; add one using ranlib(1)
> ld: Undefined symbol 
>    _free__t6Malloc2Z18Shared_Memory_PoolZ13PROCESS_MUTEXPv 
>    _free__t6Malloc2Z17Local_Memory_PoolZ10Null_MutexPv 
>    _malloc__t6Malloc2Z18Shared_Memory_PoolZ13PROCESS_MUTEXUl 
>    _malloc__t6Malloc2Z17Local_Memory_PoolZ10Null_MutexUl 
>    _remove__t6Malloc2Z17Local_Memory_PoolZ10Null_Mutex 
>    ___t6Malloc2Z17Local_Memory_PoolZ10Null_Mutex 
>    _print_stats__t6Malloc2Z17Local_Memory_PoolZ10Null_Mutex 
>    _remove__t6Malloc2Z18Shared_Memory_PoolZ13PROCESS_MUTEX 
>    ___t6Malloc2Z18Shared_Memory_PoolZ13PROCESS_MUTEX 
>    _print_stats__t6Malloc2Z18Shared_Memory_PoolZ13PROCESS_MUTEX 
> collect2: ld returned 2 exit status
> gcc: file path prefix `static' never used
> make[2]: *** [test_malloc] Error 1
> make[2]: Leaving directory `/usr2/tss/jvm/ACE_wrappers/tests/Shared_Malloc'
> <========     End all: /usr2/tss/jvm/ACE_wrappers/tests/Shared_Malloc

	That looks like a problem that G++ has with templates.  I
don't know of any reasonable solution to this problem using g++.

> Finally decided there was enough stuff that it looked like I might have some
> thing so I tried to run some tests and could not find so much as one piece
> of documentation that might give me some clue about running tests.

You should take a look at ./tests/Service_Configurator/server/README
file.  That explains how to run the more complicated tests.  As for
the other tests, it is pretty straight forward if you look at the
./tests/IPC_SAP/SOCK_SAP and ./tests/Reactor/* directory code to
figure out how to run the tests.  I don't have a Q/A department, so
any documentation has to come from volunteers.

----------------------------------------
4. Is there any docs or man pages on the Log_Record class?

There is a paper in the C++_wrappers_doc.tar.Z file on ics.uci.edu
called reactor2.ps that has some examples of using Log_Record.  The
./apps/Logger directories show several examples using Log_Record.  
Finally, the source code for Log_Record is pretty short (though it
clearly could be commented better ;-)).

----------------------------------------
5. Signal handling prototypes

> According to the man page on sigaction on our system, that line
> should look something like the following:
> 
>       sa.sa_handler = SIG_DFL;

	The problem is that most versions of UNIX I've come across
don't have a correct prototype for this field of struct sigaction.
That's why I define two variants of signal handler typedefs: one that
is a typedef of the "correct version" (which I call SignalHandler) and
one of which is a typedef of the "incorrect version" (which I call
SignalHandlerV).  You might check out the sysincludes.h file to see
how it is defining SignalHandlerV and make sure this matches what your
OS/Compiler defines in <sys/signal.h>

----------------------------------------
6. Omitting shared libraries

> Can anyone tell me a way to turn off the creation of the shared libraries
> in the ACE build.

You can simply comment out the LIB target in the $ACE_ROOT/ace/Makefile
or change the BUILD target from

BUILD	= $(VLIB) $(VSHLIB) $(SHLIBA)

to

BUILD	= $(VSHLIB) $(SHLIBA)

----------------------------------------
7. DCE threading and signal handling

>Reading the DCE docs leaves me confused as to how to make everyone
>work together in a happy hormonious whole. May basic need is to catch
>asynchronous signals so i can release some global resources before
>the process exits.

You need to spawn a separate thread to handle signals.  As part of
your init, do this:
	pthread_create(&tid, thread_attr, signal_catcher, NULL);
	pthread_detach(&tid);

Where signal_catcher is like this:
static void *
signal_catcher(void *arg)
{
    static int		catch_sigs[] = {
	SIGHUP, SIGINT, SIGQUIT, SIGTERM, SIGCHLD
    };
    sigset_t		catch_these;
    int			i;
    error_status_t	st;

    for ( ; ; ) {
	sigemptyset(&catch_these);
	for (i = 0; i < sizeof catch_sigs / sizeof catch_sigs[0]; i++)
	    sigaddset(&catch_these, catch_sigs[i]);
	i = sigwait(&catch_these);
	/* Note continue below, to re-do the loop. */
	switch (i) {
	default:
	    fprintf(stderr, "Caught signal %d.  Exiting.\n", i);
	    CLEANUP_AND_EXIT();
	    /* NOTREACHED */
#if	defined(SIGCHLD)
	case SIGCHLD:
	    srvrexec__reap();
	    continue;
#endif	/* defined(SIGCHLD) */
	}
    }
    return NULL;
}
----------------------------------------
8.

> I have installed ACE2.15.5 on SunOS 4.1.3 with gcc2.6.0. I run the test program
> ---server_test. The static is OK, but error found when I commented out the first
> one and uncommented out the second one in the svc.conf file: 
> 
> #static Svc_Manager "-d -p 3912"
> dynamic Remote_Brdcast Service_Object * .shobj/Handle_Broadcast.so:remote_broad
> cast "-p 10001"
> 
> The error goes like this:
> 
> -----------
> jupiter[12] %server_test -d
> starting up daemon server_test
> opening static service Svc_Manager
> did static on Svc_Manager, error = 0
> signal signal 1 occurred
> beginning reconfiguration at Sat Feb 25 13:40:29 1995
> Segmentation fault (core dumped)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

My guess is that the code generated by GCC on SunOS 4.x does not
correctly initialize static variables from shared libraries.  The
SunC++ 4.0.x compiler does this correctly on Solaris 2.x (though I
believe that on SunOS 4.x it doesn't work without some extra coaxing).

In general, I try to avoid using ACE's explicit dynamic linking
mechanisms on SunOS 4.x and GCC.  You can write plenty of interesting
and useful code with ACE without using those features.  Those tests
are mostly there to illustrate the "proof of concept."
----------------------------------------
9. 

> a) I noticed the default constructor for the reactor does an open w/ defaults.
>    Does this mean I need to close it if I wish to re-open it with different
>    size and restart values?

	No.  With the latest versions of ACE, you can now just call
open() with a new size and it will correctly resize the internal
tables to fit.

> b) What is the usage difference between the normal FD_Set objects 
>    (rd/wr/ex_handle_mask_) and the ready FD_Set objects 
>    (rd/wr/ex_handle_mask_ready)?

	The normal FD_Sets (now called Handle_Set in ACE 3.0.5) holds
the "waitable" descriptors (these are the descriptors given to
select() or poll()).  In contrast, the ready FD_Sets may be set by
Event_Handler subclasses (by called the set_ready() API) to indicate
to the Reactor that they want to be redispatched on the next go-round
*without* blocking.  If you look at the Reactor code, you'll see that
the wait_for() method checks the ready sets first and doesn't block if
there are any bits set in those masks.  This features makes it
possible for Event_Handlers to control subsequent dispatching policies
of the Reactor.

> c) What does the positive return value do from an event handler callback:
>   -1 detaches the event handler for that mask
>    0 does nothing - keeps the event handler registered for that mask
>   >0 resets a bit in the current dispatching mask (I think) - does this mean 
>    this event will be called again before the current dispatch cycle is done?

Almost...  (it's tied in with my description of the ready sets above).
It means that once the Reactor finishes cycling through the set of
descriptors it got back from select() or poll(), it will redispatch
the ready set descriptors before sleeping.

>    Without direct access to the bit masks in X, I'm not sure I could emulate
>    this activity - what do you think?

I'm not sure.  I'm not enough of an X guru.  Maybe someone else on the
list knows the answer to this?

> d) If I let X do the select blocking, will that have any affect on 
>    the Reactor performing signal handling? 

	Yes, I think that will cause problems since the Reactor relies
on a "handshake" between its Signal_Handler component and its
handle_events loop to properly handle signals.

> e) Is the Poll method preferred over Select if it is available - why?

For systems that implement select() in terms of poll() (e.g., Solaris
2.x) then it may be somewhat faster.  Otherwise, it doesn't really
matter since (1) they (should) do the same thing and (2) the end user
shouldn't notice any change in behavior.

----------------------------------------
10. 

> I would very much like to evaluate/use the ACE Toolkit,
> but am limited as to disk space on our system.
> What is the total disk space required for a compiled,
> usable toolkit?

The source code itself is around 2 Meg, uncompressed.  

The compiled version of ACE is around 90 Meg compiled with the SunC++
4.x compiler (naturally, this will differ with other compilers).
However, of this amount, about 40 meg are for the libraries, and
another 50 meg are for the test programs.  Naturally, you don't need
to keep the test programs compiled.

The postscript documentation is around 5 Meg, compressed.

----------------------------------------
11.

> This is regarding the newer release of ACE and pertaining to the library
> archive file. My question is, if all the ".o" files are archived into one
> single "libACE.a", does it increase the size of the executable program?

No.  The use of a *.a file allows the linker to extract out only those
*.o files that are actually used by the program.

> If it does, then does a large executable program mean possibility of it being 
> slower?

	No.

----------------------------------------
12.

> What happens if I have several reactors in a process (e.g. in different 
> threads)?
> 
> Programmer 1 decides to register at reactor 1 in his thread 1 a signal handler 
> for SIGUSR.
> Programmer 2 decides to register at reactor 2 in his thread 2 a signal handler
> for SIGUSR.

	Naturally, the behavior of this all depends on the semantics
of the threads package...  In Solaris 2.x, signal handlers are shared
by all threads.  Moreover, the Reactor uses a static table to hold the
thread handlers.  Thus, only one of the handler's would be registered
(i.e., whichever one was registered second).

> Programmer 3 designs the process and decides to have thread 1 and thread 2
> running in the same process and also makes use of a third party software library
> that internally has also registered a signal handler (not at the reactor) for
> SIGUSR.

	Now you've got big problems!  This is an example of a
limitation with UNIX signal handlers...  In general, it's a bad idea
to use signal handlers if you can avoid it.  This is yet another
reason why.

> When looking into Ace/ACE_wrappers/tests/Reactor/misc/signal_tester.C you
> have shown a way to do this by marking the dummy file_descriptor of the
> Sig_Handler object ready for reading asynchronously. The handle_input()
> routine of Sig_Handler object will then be dispatched synchronously.
> But what happens if I have several reactors. 
> The asynchronously dispatched
> handle_signal() routine does not know via which reactor it has been registered
> so in which reactor to modify the dummy file_descriptor.
> Is your suggestion to have just one process global reactor in such a case?

	Yes, precisely.  I would *strongly* recommend against using
several reactors within separate threads within the same process if
you are going to be having them handle signals.  Can you use 1
reactor and/or have one reactor handle signals within a process?

> One thing we want to do is the priorization of Event_Handlers. I.e. in case
> of concurrent events the sequence in which the Event_Handler methods will be
> activated depends on their priority relative to each other. 
> We have two choices:
> - complete priorization, which means a high priority Input Event_Handler may
>   be activated prior to a lower prioritized Output Event_Handler (and doing
>   so violating the 'hardcoded rule' that output must be done prior to input).
> - priorization only in categories, which means all Output Event_handler are
>   ordered by their priority regardless of priorities for the category of Input
>   Event_Handlers. The priority is fixed between the categories, i.e. first
>   output then input then out-of-band.
> 
> Right now I would think that we have to use the second choice if we want to
> use the feature of asynchronous output with automatical re-queueing. Am I right
> ?

	Hum, that's an interesting problem.  It might be better to
subclass the Reactor to form a new class called Priority_Reactor.
This subclass would override the Reactor's dispatch method and
dispatch the event handlers in "priority" order.  I've never done
that, but I don't think it would be all that difficult.

----------------------------------------
13. 

> 	Is the Orbix (aka CORBA) version still around?

Nope, IONA does not support Orbix-2.X nor Orbix-3.0 anymore (the
versions of Orbix that the ACE code was based upon).  Plus we didn't
maintain this code for ages, so it probably was broken too.

----------------------------------------
14. 
> We are using your ACE software and ran into a problem which may or may not
> be related to the mutex locks.  The question may have more to do with how 
> mutex locks should be used.  We had a class which was using your mutex 
> lock wrapper.  Each member function of the class acquired the lock before 
> processing and released on exiting the function.  Some member functions may 
> call other member functions.  The following is an example:
> 
> class foo {
> 
> void a()
> {
>   MT( Mutex_Block<Mutex> m( this->lock_ ));
> 
>   if( cond )
>     b();
> }
> 
> void b()
> {
>   MT( Mutex_Block<Mutex> m( this->lock_ ));
> 
>   if( cond )
>     a();
> }
> 
> };
> 
> Is this valid ?  My assumtpion is that the mutex lock is recursive and 
> the same thread can acquire the lock multiple times in different member
> functions.

	Ah, that's a great question since there are subtle and
pernicious problems lurking in the approach you are trying above.
Basically, Solaris mutex locks are *not* recursive (don't ask why...)
Thus, if you want to design an application like the one above you'll
need to use one or more of the following patterns:

----------------------------------------
A. Use recursive mutexes.  Although these are not available in
   Solaris directly they are supported in the later versions
   of ACE.  You might want to take a look at the latest
   version (./gnu/ACE-3.1.9.tar.Z).  It's got lots of new
   support for threading and synchronization.  In that case,
   you simply do the following:

	class Foo 
	{
	  public:
	  void a()
	  {
	    MT( Guard<Recursive_Lock <Mutex> > m( this->lock_ ));
	    b ();
	  }

	  void b()
	  {
	    MT( Guard<Recursive_Lock <Mutex> > m( this->lock_ ));
	    b_i ();
	  }

	};

   The advantage with this is that it requires almost no
   changes to existing code.  The disadvantage is that
   recursive locks are just slightly more expensive.

B. Have two layers of methods (a) which are public and acquire
   the Mutex and then call down to methods in layer (b), which
   are private and do all the work.  Methods in layer b assume
   that the locks are held.  This avoids the deadlock problem
   caused by non-recursive mutexes.  Here's what this approach
   looks like (using the more recent ACE class names):

	class Foo 
	{
	  public:
	  void b()
	  {
	    MT( Guard<Mutex> m( this->lock_ ));
	    b_i ();
	  }

	  void b_i()
	  {
	    if( cond )
	      a_i();
	  }

	  void a_i()
	  {
	    if( cond )
	      b_i();
	  }

	  void a()
	  {
	    MT( Guard<Mutex> m( this->lock_ ));
	    a_i ();
	  }

	};

    The advantage here is that inline functions can basically
    remove all performance overhead.  The disadvantage is that
    you need to maintain two sets of interfaces.

C. Yet another approach is to release locks when calling
   other methods, like this:

	class Foo 
	{
	  public:
	  void b()
	  {
	    MT( Guard<Mutex> m( this->lock_ ));
	    m.release ();
	    a ();
	    m.acquire ();
	  }

	  void a()
	  {
	    MT( Guard<Mutex> m( this->lock_ ));
	    m.release ();
	    b ();
	    m.acquire ();
	  }

	};

   The disadvantage with this, of course, is that you
   greatly increase your locking overhead.  In addition,
   you need to be very careful about introducing race
   conditions into the code.  The primary reason for
   using this approach is if you need to call back to
   code that you don't have any control over (such as
   OS I/O routines) and you don't want to hold the 
   lock for an indefinite period of time.
----------------------------------------
	   
	BTW, all three of these patterns are used in the ACE Reactor
class category.  The Reactor has a number of fairly complex
concurrency control and callback issues it must deal with and I've
found it useful to use all three of these patterns jointly.

	I'd be interested to hear any comments on these approaches.
	
	Doug
----------------------------------------
15. 

> I am working on Solaris 2.3 and trying to understand how to get around
> the problem of trying to open a Socket connection to a remote host that
> is "dead".  Of course you get a nice long process block if the socket
> is in Blocking mode (TCP lets you know when you can continue - how polite). 
>
> So how does a non-blocking connect work with respect to using
> the Reactor and a SOCK_Stream object to coordinate the opening
> of the connection? Do I wait on the OUTPUT event for the FD?
> How do I know if the connect worked or possibly timed-out?  Is
> this a reliable approach (I read somewhere that this will only
> work if the STREAMS module is at the top of the protocol stack
> - MAN page I think)?

An example of implementing this is in the Gateway sample application
in the new ACE.  It's also encapsulated in the Connector<> pattern of
the Connection class category in ./libsrc/Connection.  You may want to
take a look at those two things for concrete usage examples.

However, the basics of getting non-blocking to work are:
- set socket to non-blocking
- initiate connect() request
- if connect() returned 0 you're connected
- if connect() returned -1 and errno is EWOULDBLOCK (or EAGAIN, depending  
on where you are), then register an event handler for read and write events  
on the socket
- any other errno value is fatal

When an event is returned
- no matter which event you get back (read or write), you may have gotten  
the event out of error.  Thus, re-attempt the connect() and check to see if  
errno is EISCONN (if it's not there's a problem!)
- if errno was EISCONN, the connection is ready to go, otherwise you must  
handle an error condition

If you want to "time out" after a certain period of time, consider  
registering for a timer event with Reactor.  If the timer goes off before  
the connection succeeds, close down the appropriate socket.

> Is using a separate thread to make the connection a better way to avoid
> the potentialy long block in the main thread during the connect call?

You could do that, but it can all be accomplised in a single process using  
the facilities available.
----------------------------------------
16. 

> I was wondering, does the Reactor class have the ability to prioritize 
> activity on the registered event handlers?

	The default strategy for the Reactor's dispatch routine
(Reactor::dispatch) does not prioritize dispatching other than to
dispatch callbacks in ascending order from 0 -> maxhandlep1.

> We have a requirment to be able to process both real-time, as well as, stored
> telemetry and ERMs concurrently.  Real-time needs to be processed at a higher
> priority than stored data.  Our design is based on both real-time and stored 
> data coming into our process via separate sockets.  

	I can think of several ways to do this:
	
	1. Use dup() or dup2() to organize your sockets such that the
	   higher priority sockets come first in the Handle_Sets that
	   the Reactor uses to dispatch sockets.  This is pretty easy
	   if you don't want to muck with the Reactor code at all.

	2. You could subclass Reactor::dispatch() and revise it so
	   that it dispatches according to some other criteria that
	   you define in order to ensure your prioritization of
	   sockets.

BTW, I'm not sure what you mean by "real-time" but I assume that you
are aware that there is no true "real-time" scheduling for network I/O
in Solaris.  However, if by "real-time" you mean "higher priority"
then either of the above strategies should work fine.  
----------------------------------------
17. 

> 	I compiled the new ACE 3.2.0 's apps/Gateway. The compiling went
> through without any errors. But I could not get it running,  neither single
> threaded nor multi-threaded. The cc_config and rt_config files entries are given
> below. Also the machine configurations are given below. Does it need some more 
> settings or some patch !!??

	I believe you are seeing the effects of the dreaded Sun MP bug
with non-blocking connects.  The easy work around for now is simply to
give the "-b" option to the Gateway::init() routine via the svc.conf
file:

dynamic Gateway Service_Object *.shobj/Gateway.so:_alloc_gatewayd() active 
				"-b -d -c cc_config -f rt_config"

If you check line 137 of the Gateway::parse_args() method you'll see
what this does.
----------------------------------------
18.

How to get ACE to work with GCC C++ templates.

The first and foremost thing to do is to get the latest version of GCC
(2.7.2) and also get the template repository patches from

ftp://ftp.cygnus.com/pub/g++/gcc-2.7.1-repo.gz

This will get the ball rolling...

Here is some more info on G++ templates courtesy of Medhi TABATABAI
<Mehdi.TABATABAI@ed.nce.sita.int>:

Where's the Template?
=====================

   C++ templates are the first language feature to require more
intelligence from the environment than one usually finds on a UNIX
system.  Somehow the compiler and linker have to make sure that each
template instance occurs exactly once in the executable if it is
needed, and not at all otherwise.  There are two basic approaches to
this problem, which I will refer to as the Borland model and the
Cfront model.

Borland model
     Borland C++ solved the template instantiation problem by adding
     the code equivalent of common blocks to their linker; template
     instances are emitted in each translation unit that uses them, and
     they are collapsed together at run time.  The advantage of this
     model is that the linker only has to consider the object files
     themselves; there is no external complexity to worry about.  This
     disadvantage is that compilation time is increased because the
     template code is being compiled repeatedly.  Code written for this
     model tends to include definitions of all member templates in the
     header file, since they must be seen to be compiled.

Cfront model
     The AT&T C++ translator, Cfront, solved the template instantiation
     problem by creating the notion of a template repository, an
     automatically maintained place where template instances are
     stored.  As individual object files are built, notes are placed in
     the repository to record where templates and potential type
     arguments were seen so that the subsequent instantiation step
     knows where to find them.  At link time, any needed instances are
     generated and linked in.  The advantages of this model are more
     optimal compilation speed and the ability to use the system
     linker; to implement the Borland model a compiler vendor also
     needs to replace the linker.  The disadvantages are vastly
     increased complexity, and thus potential for error; theoretically,
     this should be just as transparent, but in practice it has been
     very difficult to build multiple programs in one directory and one
     program in multiple directories using Cfront.  Code written for
     this model tends to separate definitions of non-inline member
     templates into a separate file, which is magically found by the
     link preprocessor when a template needs to be instantiated.

   Currently, g++ implements neither automatic model.  The g++ team
hopes to have a repository working for 2.7.0.  In the mean time, you
have three options for dealing with template instantiations:

  1. Do nothing.  Pretend g++ does implement automatic instantiation
     management.  Code written for the Borland model will work fine, but
     each translation unit will contain instances of each of the
     templates it uses.  In a large program, this can lead to an
     unacceptable amount of code duplication.

  2. Add `#pragma interface' to all files containing template
     definitions.  For each of these files, add `#pragma implementation
     "FILENAME"' to the top of some `.C' file which `#include's it.
     Then compile everything with -fexternal-templates.  The templates
     will then only be expanded in the translation unit which
     implements them (i.e. has a `#pragma implementation' line for the
     file where they live); all other files will use external
     references.  If you're lucky, everything should work properly.  If
     you get undefined symbol errors, you need to make sure that each
     template instance which is used in the program is used in the file
     which implements that template.  If you don't have any use for a
     particular instance in that file, you can just instantiate it
     explicitly, using the syntax from the latest C++ working paper:

          template class A<int>;
          template ostream& operator << (ostream&, const A<int>&);

     This strategy will work with code written for either model.  If
     you are using code written for the Cfront model, the file
     containing a class template and the file containing its member
     templates should be implemented in the same translation unit.

     A slight variation on this approach is to use the flag
     -falt-external-templates instead; this flag causes template
     instances to be emitted in the translation unit that implements
     the header where they are first instantiated, rather than the one
     which implements the file where the templates are defined.  This
     header must be the same in all translation units, or things are
     likely to break.

     *See Declarations and Definitions in One Header: C++ Interface,
     for more discussion of these pragmas.

  3. Explicitly instantiate all the template instances you use, and
     compile with -fno-implicit-templates.  This is probably your best
     bet; it may require more knowledge of exactly which templates you
     are using, but it's less mysterious than the previous approach,
     and it doesn't require any `#pragma's or other g++-specific code.
     You can scatter the instantiations throughout your program, you
     can create one big file to do all the instantiations, or you can
     create tiny files like

          #include "Foo.h"
          #include "Foo.cc"
          
          template class Foo<int>;

     for each instance you need, and create a template instantiation
     library from those.  I'm partial to the last, but your mileage may
     vary.  If you are using Cfront-model code, you can probably get
     away with not using -fno-implicit-templates when compiling files
     that don't `#include' the member template definitions.

4. Placing a function that looks like this near the top of a .C file
   that uses any inline template member functions permits proper inlining:

   // #ifdef __GNUG__
   // This function works around the g++ problem with inline template member
   // calls not being inlined ONLY in the first block (in a compilation
   // unit) from which they are called.
   // This function is inline and is never called, so it does not produce
   // any executable code.  The "if" statements avoid compiler warnings about
   // unused variables.
   inline
   void
   gcc_inline_template_member_function_instantiator()
   {
       if ( (List<FOO> *) 0 );
   }
   // #endif  // __GNUG__

   other prerequisites:
   -- All inline template member functions should be defined in
      the template class header.  Otherwise, g++ will not inline
      nested inline template member function calls.
   -- Template .h and .C files should NOT include iostream.h
      (and therefore debugging.h).
      This is because iostream.h indirectly includes other
      GNU headers that have unprotected #pragma interface,
      which is incompatible with -fno-implicit-templates and optimal
      space savings.
   -- inline virtual destructors will not be inlined, unless necessary,
      if you want to save every last byte
   -- be sure that -Winline is enabled

----------------------------------------
19.

> 	1. when are dynamically loaded objects removed from the Service_Config.

The Service Configurator calls dlclose() when a "remove Service_Name"
directive is encountered in the svc.conf file (or programmatically
when the Service_Config::remove() method is invoked).  Check out the
code in ./libsrc/Service_Config/Service_Repository.i and
./libsrc/Service_Config/Service_Config.i to see exactly what happens.

> 	2. In the Service Configurator, when an item is entered in the svc.conf
> 		how dow you know which items will be invoked as threads and 
> 		which items are forked. I know that static items are executed 
> 		internally. 

	No!  It's totally up to the subclass of Service_Object to
decide whetehr threading/forking/single-threading is used.  Check out
the ./apps/Logger/Service_Configurator_Logger for examples of
single-threaded and multi-threaded configuration.
----------------------------------------
20. 

> I have been reading the Service Configurator Logger. I was wondering about 
> cleanup of new objects. In the handle_input method for the Acceptor a new
> svc_handler is allocated for each new input request and deleted in the 
> handle_close. I was wondering how handle close was called when a client who
> has created a socket terminates the connection (i.e., when is handle_close
> called).

handle_close() is automatically called by the Reactor when a
handle_input()/handle_output()/etc. method returns -1.  This is the
"hook" that instructs the Reactor to call handle_**() and then remove
the Event_Handler object from its internal tables.

----------------------------------------
21. 

> How does the Logger know to remove the client socket and the svc_handler object.
> Does he recieve an exception. 

	No.  when the client terminates the underlying TCP/IP
implementation sends a RESET message to the logger host.  This is
delivered to the logger process as a 0-sized read().  It then knows to
close down.

> What I am worried about is a leak. Where by alot of clients connect and 
> disconnect and the server does not cleanup correctly. Such as a core dump
> from the client where he cannot close correctly.

	That's handled by the underlying TCP (assuming it is
implemented correctly...).

> What I am doing is attempting to convert the logger example into an alarm
> manager for remote nodes. In this application a node may be powered down
> there by terminating a Logger/Alarm server connection abnormally, this could
> leave the Logger with many dangling sockets and allocated svc_handler objects.

	If the TCP implementation doesn't handle this correctly then
the standard way of dealing with it is to have an Event_Handler use a
watchdog timer to periodically "poll" the client to make sure it is
still connected.  BTW, PCs tend to have more problems with this than
UNIX boxes since when they are turned off the TCP implementation may
not be able to send a RESET...
----------------------------------------
22. 

Using templates with Centerline.

Centerline uses ptlink to process the C++ templates. ptlink expect the
template declarations and definitions (app.h and app.C) to reside in
the same directory. This works fine for the ACE hierarchy since
everything is a link to the appropriate src directory (include/*.[hi]
--> ../src/). When a users of the ACE distribution attempts to include
the ACE classes in an existing application hierarchy this problem will
arise if ptlink is used.

The solution is to create a link to the declaration file from the
definition file directory and use the "-I" to point to the definition
directory.

----------------------------------------

23. 

> When I try to compile $ACE_ROOT/src/Message_Queue.C on a Solaris
> 5.3 system using SUNPro CC 4.0, the compiler aborts with a Signal 10
> (Bus Error).  Our copy of CC 4.0 is over a year old and I do not
> know if any patches or upgrades exist for it.  If they do, then we
> have not applied them to our compiler.

	Several other people have run across this as well.  It turns
out that there is a bug in the Sun 4.0.0 C++ compiler that will get a
bus error when -g is used.  If you compilg Message_Queue.C *without*
-g then it works fine.  The later versions of SunC++ don't have this
bug.  I'd recommend that you upgrade as soon as possible.

----------------------------------------

24. 

> I have added a dynamic service to the Service Configurator. This new service
> fails on the load because it uses application libraries that are not shared 
> object libraries (i.e., objects in libApp.a). I am assuming from the error
> message that the problem is the mix match of shared and non-shared objects.

	Right, exactly.

> I was wondering if there is an easy way to add static services to the 
> Service Configurator. The example directory listing static service is
> very tightly coupled with the Service_Config object. Is there another
> way of adding static services.

	Sure, that's easy.  The best way to do this is to use the
interfaces of the Service_Respository class to configure static
services into the Service_Config.  A good example of how to do this is
in Service_Config.[Chi]:

int
Service_Config::load_defaults (void)
{
  for (Static_Svc_Descriptor *sl = Service_Config::service_list_; sl->name_ != 0; sl++)
    {
      Service_Type *stp = ace_create_service_type (sl->name_, sl->type_, 
						   (const void *) (*sl->alloc_)(),
						   sl->flags_);
      if (stp == 0)
	continue;

      const Service_Record *sr = new Service_Record (sl->name_, stp, 0, sl->active_);

      if (Service_Config::svc_rep->insert (sr) == -1)
	return -1;
    }
  return 0;
}

----------------------------------------
25. 

> 8. Do you have examples of the SYNC/ASYNC pattern?

	Yes.  Check out the following:
	
	1. The latest version of ./apps/Gateway/Gateway has
	   an example of this when you compile with the USE_OUTPUT_MT 
	   flag.  In this case, the Reactor performs the "Async"
	   processing, which multiplexes all incoming messages from peers
	   arriving on Input_Channels.  These messages are then queued
	   up at the appropriate Output_Channels.  Each Output_Channel
	   runs in a separate thread, performing the "Sync"
	   processing.
	   
	2. Also, the latest version of the OOCP-tutorial4.ps.gz
	   file available from wuarchive.wustl.edu in the
	   directory /languages/c++/ACE/ACE-documentation shows
	   an example of using the Half-Sync/Half-Async pattern
	   to build an Image Server.  I'm using this as an
	   example in my tutorials these days.

----------------------------------------
26.

> We had a discussion about something we saw in the new ACE code.
> I thing there was a member function of a class that was doing a 
> "delete this".  Is this safe?

In general it is safe as long as (1) the object has been allocated
dynamically off the heap and (2) you don't try to access the object
after it has been deleted.  You'll note that I tend to use this idiom
in places where an object is registered with the Reactor, which must
then must ensure the object cleans itself up when handle_close() is
called.  Note that to ensure (1) I try to declare the destructor
"private" or "protected" so that the object must be allocated off the
heap (some compilers have a problem with this, so I may not be as
consistent as I ought to...).

----------------------------------------
27. 

> 5. What is the correct way for building a modified ACE library?
> 	Changing in "libsrc" or in "include" directory?
> 	When I make a complete new directory, how can I get introduced
> 	the dependencies within my new makefile, can you give a short hint?

Sure, no problem.  For instance, here's what I did tonight when I
added the new Thread_Specific.[hiC] files to ACE:

	1. Created three new files Thread_Specific.[hiC] in
	   ./libsrc/Threads. 

	2. cd'd to ../../include/ace and did a
	
	   % ln -s ../../libsrc/Threads/Thread_Specific.[hi] .
	   
	3. cd'd to ../../src and did a 	   

	   % ln -s ../../libsrc/Threads/Thread_Specific.C .

	4. then I did
	
	   % make depend

	   on the ./src directory, which updated the dependencies. 

----------------------------------------
28. The following is from Neil B. Cohen (nbc@metsci.com), who is
    writing about how to work around problems he's found with HP/UX.

I've been trying to compile the latest beta (3.2.9) on an HP running
HPUX9.05 for the past week or so. I've had problems with templates up
and down the line. I finally discovered (after some discussions with
the HP support people) that they have made numerous changes to their
C++ compiler recently to fix problems with templates and
exceptions. If you are trying to compile ACE under HPUX with anything
less than version 3.70 of the HP compiler, you may have serious
problems (we were using v3.50 which came with the machine when we
bought it a few months ago).

Also, unlike earlier ACE versions, I was forced to add the following
line to the rules.lib.GNU file to "close" the library - ie. force the
various template files to be instantiated and linked to the ACE
library itself. I don't know if this is necessary, or the only way to
make things work, but it seems to do the job for my system.

in rules.lib.GNU...

$(VLIB): $(VOBJS)
    - CC -pts -pth -ptb -ptv -I$(ACE_ROOT)/include $(VOBJS)
    $(AR) $(ARFLAGS) $@ $? ./ptrepository/*.o
    -$(RANLIB) $@
    -chmod a+r $@

I added the CC line, and added the "./ptrepository/*.o" to the $(AR)
cmd.  Sun has an -xar option, I believe that does something similar to
this.  Also - note that I'm not sure that the "-ptb" option is
necessary. I added that before we upgraded the compiler, so it may not
be needed now...

----------------------------------------
29. 

> I just ran my program with Purify, and it is telling me that there
> is at least one large (~4k) memory leak in
> ACE_Thread_Specific<ACE_Log_Msg>.  This may or may not be serious,
> but it is probably worth looking into.

Right, that's ok.  This is data that's allocated on a "per-thread"
basis the first time a thread makes a call using the LM_ERROR or
LM_DEBUG macros.  The data isn't freed-up until the thread exits.

----------------------------------------

30. 

>     In my trying to use the Reactor pattern for my application I
> noticed that I had to couple my eventHandler derived objects with a
> specific IPC_SAP mechanism. To use some of your own examples your
> Client_Stream object contains a TLI_Stream object to use in data
> transfer. My application calls for determining the communication
> mechanism at run time. To do this my eventHandler must be able to
> create the appropriate IPC_Stream object at run time and use its
> methods through a super class casting. The problem is that there is no
> super class with the virtual methods for send, recv, etc. To solve my
> problem I will create that super class and have the TLI ( as well as
> other wrapper objects) inherit from it instead of IPC_SAP. My question
> is I am suspicious of why ACE wasn't designed with that in mind? Is my
> application that unique ? or is there a better way to do this that I
> am not aware of ?  Your help in this matter will be much appreciated.

ACE was developed using static binding for IPC_SAP in order to
emphasize speed of execution over dynamic flexibility *in the core
infrastructure*.  To do otherwise would have penalized the performance
of *all* applications in order to handle the relatively infrequent
case where you want to be able to swap mechanisms at run-time.

Since it is straightforward to create an abstract class like the one
you describe above I decided to make this a "layered" service rather
than use this mechanism in the core of ACE.

BTW, I would not modify TLI_SAP and SOCK_SAP to inherit from a new
class. Instead, I would use the Bridge and Adapter patterns from the
"Gang of Four" patterns catalog and do something like this:

----------------------------------------
// Abstract base class
class ACE_IPC_Stream
{
public:
	virtual ssize_t recv (void *buf, size_t bytes) = 0;
	virtual ssize_t send (const void *buf, size_t bytes) = 0;
	virtual ACE_HANDLE get_handle (void) const = 0;
	// ...
};
----------------------------------------

and then create new classes like 

----------------------------------------
template <class IPC>
class ACE_IPC_Stream_T : public ACE_IPC_Stream
{
public:
	virtual ssize_t recv (void *buf, size_t bytes)
	{
		return this->ipc_.recv (buf, bytes);
	}

	virtual ssize_t send (const void *buf, size_t bytes)
	{
		return this->ipc_.send (buf, bytes);
	}

	virtual ACE_HANDLE get_handle (void)
	{
		return this->ipc_.get_handle ();
	}
	// ...

private:
	IPC ipc_;
	// Target of delegation 
	// (e.g., ACE_SOCK_Stream or ACE_TLI_Stream).
}
----------------------------------------

Then you could write code that operated on ACE_SAP *'s to get a
generic interface, but that reused existing code like SOCK_SAP and
TLI_SAP, e.g.,

----------------------------------------
class My_Event_Handler : public ACE_Event_Handler
{
public:
	My_Event_Handler (void) {
		// Figure out which IPC mechanism to use somehow:
		
		if (use_tli)
			this->my_ipc_ = new ACE_SAP_IPC<ACE_TLI_Stream>;
		else if (use_sockets)
			this->my_ipc_ = new ACE_SAP_IPC<ACE_SOCK_Stream>;
		else
			...
	}

private:
	ACE_IPC_Stream *my_ipc_;
};
----------------------------------------

There are obviously details left out here, but this is the general idea.

----------------------------------------
31. 

> I was trying to view your 'Writting example applications in CORBA' article
> /tutorial using ghostview but the .ps file seems to be corrupted ( I tried to
> ftp it more than once). Any help would be much appreciated.

There are two solutions to this problem (which seems to be caused by a
weird interaction between ghostview and the "psnup" program I use to
generate the slides 4-up on a page):

	1. If you want to print them or view them 1-up on a page you
	   can edit the postscript file and remove the first 551
	   lines or so (which are generated by the psnup script).
	   This will cause the document to be printed 1-up rather than
	   4-up.

	2. You can try to print the 4-up file on a postscript printer. 
	   Believe it or not, this typically works, even though ghostview
	   can't handle it!

----------------------------------------
32.

> We would like to use the Reactor class as a static member on some of
> our classes (one per process) so that we can see and use the Reactor
> witnin each process on a global level.  We are using it to set
> timers several levels down in our class trees and don't want to pass
> a pointer to it through all of our constructors.  My question is:
> are there any static initialization dependencies that you know of
> when using the default "do nothing" constructor of the Reactor that
> could prevent use from using it as a static member variable?  Thanks
> for any advice on this issue.

The only problems you'll have are the typical ones about "order of
initialization" of statics in separate files.  You'll also have to
live with the default size of the I/O handler table, which probably
isn't a problem since the max is something like 1024 or so.

BTW, I solve this problem in ACE via the Service_Config::reactor,
which is a static *pointer* to a Reactor.  If you really wanted to
make this work nicely, you could use the Singleton pattern from the
"Gang of Four" patterns catalog.  That should solve your problem even
more elegantly!

----------------------------------------
33. 
> I just got the ACE-3.3 version and am trying it on the HP-UX.
> I run into a small problem while cloning the directories that
> might be worth fixing.
> 
> I made a directory called ACE_WRAPPERS/HP-UXA.09.05-g1, cd to it
> and run "make -f ../Makefile clone".  when I look in src, I have:
> Acceptor.C@ -> ../libsrc/Connection/Acceptor.C
> 
> However, ../libsrc does not exist.  It is not one of the CLONE
> variables in ACE_WRAPPERS/Makefile.  I don't think you'd want to
> clone libsrc too, since its files don't change.

I think you can solve this problem as follows:

% cd ACE_WRAPPERS
% setenv ACE_ROOT $cwd
% cd HP-UXA.09.05-g1
% make -f ../Makefile clone
% setenv ACE_ROOT $cwd
% make

That should build the links correctly since they'll point to the
absolute, rather than relative, pathnames!

----------------------------------------
34.

> Our quality personal has asked me the following questions for which
> I think you are the right guy for answering that:

> o How long is ACE used in industrial products?

It was first used at Ericsson starting in the fall of 1992, so that
makes it about 3 years now.

> o What are reference projects comparable to ours that use ACE?

The ones I have directly worked with include:

Motorola -- satellite communication control
Kodak Health Imaging Systems -- enterprise medical imaging
Siemens -- enterprise medical imaging
Ericsson/GE Mobile Communications -- telecommunication switch management
Bellcore -- ATM switch signal software

In addition, there are probably about 100 or more other companies that
have used ACE in commercial products.  The current mailing list has
about 300 people from about 230 different companies and universities.
If you'd like additional info, please let me know.

> o How many persons have contributed on testing and writing error
> reports for ACE?

Around 60 or so.  All the contributors are listed by name and email
address at the end of the README file distributed with the ACE release.

> o How many bug fixes have been made since ACE was public domain?

All information related to bug fixes is available in the ChangeLog
file distributed with the ACE release (I could count these for you if
you need that level of detail).

> o How many literature is there on ACE?

All articles published about ACE are referenced in the BIBLIOGRAPHY
file in the top-level directory of ACE.

----------------------------------------

35.

> We are currently evaluating ACE for use on a new telecom switch.
> Many of us like ACE but are having trouble convincing some team
> members that wrappers are better than using the direct Unix
> system calls.

> I have read your papers that came with ACE, but was wondering if there
> are other papers that address the benefits (or problems) of wrappers?

This topic has been discussed in other places, most notably the book
by Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides
called "Design Patterns: Elements of Reusable Object-Oriented
Software" (Addison-Wesley, 1994), where it is described in terms of
the "Adapter" pattern.

Very briefly, there are several key reasons why you should *not* use
UNIX system calls directly (regardless of whether you use ACE or not).

1. Portability -- 

   	Unless you plan to develop code on only 1 UNIX platform (and
   	you never plan to upgrade from that platform as it goes
   	through new releases of the OS) you'll run across many, many
   	non-portable features.   It's beyond the scope of this
        FAQ to name them all, but just take a look at ACE sometime
        and you'll see all the #ifdefs I've had to add to deal with
	non-compatible OSs and compilers.  Most of these are centralized
	in one place in ACE (in the ace/OS.*files), but it took a lot
	of work to factor this out.  By using wrappers, you can avoid
	most of this problem in the bulk of your application code
	and avoid revisiting all of these issues yourself.

        In addition, ACE is now ported to other platforms (e.g.,
        Windows NT and Windows 95).  If you want to write code that
        is portable across platforms, wrappers are a good way to
        accomplish this. 

2. Ease of programming --

	I'd go as far as to say that anyone who wants to program
   	applications using C-level APIs like sockets or TLI is not
   	serious about developing industrial strength, robust, and easy
   	to maintain software.  Sockets and TLI are *incredibly*
   	error-prone and tedious to use, in addition to being
   	non-portable.  I've got a paper that discusses this in detail
	at URL http://www.cs.wustl.edu/~schmidt/PDF/COOTS-95.pdf
	
3. Incorporation with higher-level patterns and programming methods -- 

	Here's where the Adapter pattern stuff really pays
	off.  For example, by making all the UNIX network
	programming interfaces and synchronization mechanisms
	have the same API I can write very powerful higher-level
	patterns (e.g., Connector and Acceptor) that generalize
	over these mechanisms.  For proof of this, take a look
	at the ./tests/Connection/non_blocking directory
	in the latest ACE-beta.tar.gz at wuarchive.wustl.edu
	in the /languages/c++/ACE directory.  It implements
	the same exact program that can be parameterized
	with sockets, TLI, and STREAM pipes *without*
	modifying any application source code.  It is 
	literally impossible to do this without wrappers.

----------------------------------------
36.

> How can I use a kind of "Reactor" in such a way that a reading
> thread can notice the arrival of new data on several shared memory
> areas ?

Ah, that is a tricky issue!  The underlying problem is that UNIX is
inconsistent with respect to the ability to "wait" on different
sources of events.  In this case, Windows NT is much more consistent
(but it has its own set of problems...).

> Poll, Select and Reactor (so far I read) assume that file
> descriptors are present, which is not the case with shared memory.

That's correct (though to be more precise, the Reactor can also deal
with signals, as I discuss below).  

> Is there a common and efficient way to deal with that kind of
> situation, or do I have to insert extra ipc mechanisms (based on
> descriptors) ?

There are several solutions:

1. Use the Reactor's signal handling capability (see the
   ./tests/Reactor/misc/signal_tester.C for an example)
   and have the process/thread that writes to shared 
   data send a signal to the reader process(es).  The
   disadvantage of this is that your code needs to 
   be signal-safe now...

2. Use a combination of SPIPE_Streams and the Reactor
   to implement a simple "notification protocol," e.g.,
   the receiver process has an Event_Handler with a
   SPIPE_Stream in it that can be notified when the
   sender process writes data to shared memory.
   The disadvantage here is that there's an extra
   trip through the kernel, though the overhead
   is very small since you only need to send 1 byte.

3. Use threads and either bypass the Reactor altogether
   or integrate the threads with the Reactor using its
   Reactor::notify() mechanism (see the 
   ./tests/Reactor/misc/notification.C file for an
   example of how Reactor::notify() works).  The
   disadvantage of this approach is that it won't
   work for platforms that lack threads.

----------------------------------------
37.

> What do you think about wrapping communication methodologies in C++ streams?
> What I mean is having defining a stream and extractor/insertor functions
> which the underlying implementation reads/writes on comm mechanisms instead of
> files.  I would think this to be a very general interface for all comms
> implementations.  All user code would look the same, but the underlying stream
> implementations would be different.  Whether the stream functionality would
> be defined by the stream itself (eg tcpstream) or with manipulators
> (eg commstream cs; cs << tcp;) is up for grabs in my mind.
> 
> Anyhow, I was wondering your input...

That technique has been used for a long time.  In fact, there are
several freely available versions of iostreams that do this and
RogueWave also sells a new product (Net.h++) that does this.  I think
this approach is fine for simple applications.

However, it doesn't really work well if you need to write
sophisticated distributed applications that must use features like
non-blocking I/O, concurrency, or that must be highly robust against
the types of errors that occur in a distributed system.

For these kinds of systems you either need some type of ORB, or you
need to write the apps with lower-level C++ wrappers like the ones
provided by ACE.

----------------------------------------

38.

> What is the difference between cont() and next() in an ACE_Message_Block?

Ah, good question.  cont() gives you a pointer to the next
Message_Block in a chain of Message_Block fragments that all belong to
the same logical message.  In contrast, next() (and prev()) return
pointers to the next (and previous) Message_Block in the doubly linked
list of Message_Blocks on a Message_Queue.  

BTW, this is *exactly* the same structure as in System V Streams...

> Which would I use if I wanted to add a header and a trailer, each stored in
> ACE_Message_Blocks of their own, to another ACE_Message_Block?

You should use cont() for that.  Does that make sense?
----------------------------------------

39.

> I think that your site is cool, but it's being a terrible tease in
> that I really want to read the contents, but don't know anything
> about x-gzip formatting.  I'm running Netscape 2.0 under MS Windows
> NT.

To view PostScript files under Win32 you will need a PostScript 
viewer such as GSview.  You can find GSview and Ghostscript (which is
needed to run GSview) at http://www.cs.wisc.edu/~ghost/.  

It seems that both Netscape and Internet Explorer mangles the names 
of downloaded files to reflect their content type, so *.ps.gz files 
are saved as *_ps.ps instead.  Fortunately, GSview as of version 2.2
supports gzip compressed postscript.  When set up as a viewer for
Postscript files, files with mangled names can be viewed by GSview 
without any preprocessing.

----------------------------------------

40. 

> What I am doing is
> 1. Making an ACE_SOCK_Dgram and let it choose the next available port number.
> 2. Making a message that will be broadcasted to X number of servers. This
>    message has a port number which the server will use to send its reply.
> 3. Broadcast the message to a fixed port number.
> 4. Wait for replies from the servers.
> 
> 
> It looks like I need "ACE::bind_port" to return the port number that
> it picked and "ACE_SOCK_Dgram::shared_open" will need it store the
> port number so I could call some function like
> ACE_SOCK_Dgram::get_port_number or it would need to return the port
> number instead of the handle(I could always call
> ACE_SOCK_Dgram::get_handle if I needed the handle).
> 
> Is there I way to get the port number that I have missed?

Sure, can't you just do this:

// Defaults to all "zeros", so bind will pick port.
ACE_INET_Addr dg_addr;

ACE_SOCK_Dgram dg;

dg.open (dg_addr);

dg.get_local_addr (dg_addr);

dg_addr.get_port_number ();

----------------------------------------

41. How can you rename a core file?

new_disposition.sa_handler = &Handle_Coredump_Signal;
sigemptyset(&new_disposition.sa_mask);
sigaddset(&new_disposition.sa_mask,SIGCHLD);
new_disposition.sa_flags = 0;
sigaction(SIGSEGV,&new_disposition,&old_disposition);

*****************

void
Handle_Coredump_Signal(void)
{
    int   status;
    pid_t child;
    char  new_core_name[64];
    
    if(0 == (child = fork()))
    {
	abort();
    }
    else
    {
	if(-1 == waitpid(child,&status,NULL))
	{
	    exit(-1);
	}
	sprintf(new_core_name,"core_%d",getpid());
	rename("core",new_core_name);
	exit(0);
    }
}

----------------------------------------

42. 

> I have seen 2 different inlining policies in ACE
> 
> 1) The .i file is included unconditionally by both the .h and .C file
>    and all functions in the .i file carry the "inline" keyword.

Right.  Those are for cases where I *always* want to inline those
methods.  I do this mostly for very short wrapper methods (e.g.,
read() or write()) that are likely to be on the "fast path" of an
application.

> 2) The .i file is included by the .h file ONLY if __INLINE__ is defined
>    for the compile.  This causes the functions in the .i file to be
>    compiled as inline functions (INLINE translates to inline in this case).
>    If __INLINE__ is not defined, the .i file is only included by the .C
>    file and the functions do NOT carry the "inline" keyword.

I do this for cases where it's really not essential to have those
methods inline, but some users might want to compile ACE that was if
they want to eliminate all the wrapper function-call overhead.  For
instance, I'll typically do this when I'm running benchmarks.

----------------------------------------

43. Integrating ACE and CORBA

> Our goal is to implement a CORBA-II compliant application.  I am
> trying to conceptually visualize the applicability to ACE to this
> attempt (which we're pretty excited about), and I was hoping you'd
> offer any opinions / observations that you might have.

We've successfully integrated ACE with several implementations of
CORBA (in particular Orbix 1.3 and 2.0) and used it in a number of
commercial applications.  In these systems, we use ACE for a number of
tasks, including the following:

1. Intra-application concurrency control, threading, and
   synchronization via the ACE_Thread_Manager and Synch* classes. 
   
2. Dynamic linking of services via the ACE_Service_Config.

3. Integration of event loops via the ACE_Reactor.

4. Management of shared memory via ACE_Malloc.

5. High-performance network I/O via the ACE_SOCK* wrappers.

plus many more.

You can find out more info about the ACE/CORBA integration and the
performance issues associated with it in the following paper:

http://www.cs.wustl.edu/~schmidt/PDF/COOTS-96.pdf

----------------------------------------

44. 

> Can the Reactor's event loop be called recursively?

This is not advisable.  The Reactor's dispatch() method is not
reentrant (though it is thread-safe) since it maintains state about
the active descriptors it is iterating over.  Therefore, depending on
the descriptors you're selecting on, you could end up with spurious
handle_*() callbacks if you make nested calls to the
Reactor::handle_events() method.

> For example, if I have a program that sets up some event handlers
> and then calls, in an infinite loop, ACE_Reactor::handle_events().
> Can one of the event handlers call handle_events() again if it needs
> to block, while allowing other event handlers a chance to run?

I'm not sure if this is really a good idea, even if the Reactor were
reentrant.  In particular, what good does it do for one Event_Handler
to "block" by calling handle_events() again?  The event the handler is
waiting for will likely be dispatched by the nested handle_events()
call!  So when you returned back from the nested call to
handle_events() it will be tricky to know what state you were in and
how to proceed.

Here's how I design my single-threaded systems that have to deal with
this:

  	1. I use a single event loop based on the Reactor, which acts
	   a cooperative multi-tasking scheduler/dispatcher.
	   
	2. I then program all Event_Handler's as non-blocking I/O
	   objects.  This is straightforward to do for both input and
	   output using the ACE_Reactor::schedule_wakeup() and
	   ACE_Reactor::cancel_wakeup() methods (available with the
	   latest version of ACE).  
	   
	3. Then, whenever an Event_Handler must block on I/O, it 
	   queues up its state on an ACE_Message_Queue, calls
	   ACE_Reactor::schedule_wakeup(), and returns to the 
	   main event loop so that other Event_Handlers can be
	   dispatched.  When the I/O is ready, the Reactor will
	   call back to the appropriate handle_* method, which
	   can pick up the state it left in the Message_Queue and
	   continue. 

There are a number of places to find more information on this sort of
design:

	1. $ACE_ROOT/apps/Gateway/Gateway/Channel.cpp --
	   This Gateway application example shows the C++ code.

	2. http://www.cs.wustl.edu/~schmidt/PDF/TAPOS-00.pdf --
	   This paper describes the underlying patterns.

	3. http://www.cs.wustl.edu/~schmidt/PDF/OONP-tutorial4.pdf
	   -- This tutorial explains the source code and 
	   the patterns.

BTW, I'll be describing patterns for this type of design challenge in
my tutorial at USENIX COOTS in June.  Please check out
http://www.cs.wustl.edu/~schmidt/COOTS-96.html for more info.

----------------------------------------

45. 

>   In one of my programs, a process needs to receive input from
> multiple input sources. One of the input sources is a file
> descriptor while another is a message queue. Is there a clean way to
> integrate this a message queue source into the Reactor class so that
> both inputs are handled uniformly?

Do you have multiple threads on your platform?  If not, then life will
be *very* tough and you'll basically have to use multiple processes to
do what you're trying to do.  There is *no* portable way to combine
System V message queues and file descriptors on UNIX, unfortunately.

If you do have threads, the easiest thing to do is to have a thread
reading the message queue and redirecting the messages into the
Reactor via its notify() method.  

Please take a look at the program called

examples/Reactor/Misc/notification.cpp

for an example.

----------------------------------------

46. 

> I'm writing a program to find out the address for a socket.  The
> idea is that we open an ACE_Acceptor (and will eventually perform
> accept() on it.)  Before we can do that we need to find out the
> address of the ACE_Acceptor so that we can publish it (for others to
> be able to connect to it.)  The trouble is that the call
> ACE_INET_Addr::get_host_name () prints "localhost" as the host name
> while I would like to principal host name to be printed instead.

All ACE_INET_Addr::get_host_name() is doing is calling
ACE_OS::gethostbyaddr(), which in turn will call the socket
gethostbyaddr() function.  I suspect that what you should do is
something like the following:

ACE_Acceptor listener (ACE_Addr::sap_any);

ACE_INET_Addr addr;

listener.get_local_addr (addr);

char *host = addr.get_host_name ();

if (::strcmp (host, "localhost") == 0)
{
  char name[MAXHOSTNAMELEN];
  ACE_OS::hostname (name, sizeof name);
  cerr << name << endl;
}
else
  cerr << host << endl;

----------------------------------------

47. 

> Could you please point me to stuff dealing with asynchronous cross
> platform socket calls. I want to use non blocking socket calls on
> both UNIX and NT.

Sure, no problem.  Take a look at the

./examples/Connection/non_blocking/

directory.  There are a number of examples there.  In addition, there
are examples of non-blocking connections in 

./examples/IPC_SAP/SOCK_SAP/CPP-inclient.cpp

The code that actually enables the non-blocking socket I/O is in
ace/IPC_SAP.cpp

----------------------------------------

48.

> Is ACE exception-safe?  If I throw an exception out of event 
> handler, will the Reactor code clean itself?

Yes, that should be ok.  In general, the two things to watch out for
with exceptions are:

	1. Memory leaks -- There shouldn't be any memory leaks internally
	   to the Reactor since it doesn't allocate any memory when 
	   dispatching event handlers.
	  
	2. Locks -- In the MT_SAFE version of ACE, the Reactor acquires
	   an internal lock before dispatching Event_Handler callbacks.
	   However, this lock is controlled by an ACE_Guard, whose
	   destructor will release the lock if exceptions are thrown
	   from an Event_Handler.

----------------------------------------

49.

>   I am building a Shared memory manager object using MMAP and MALLOC
> basically as:
> 
> typedef ACE_Malloc<ACE_MMAP_Memory_Pool, ACE_Process_Mutex> SHMALLOC;
> 
> I noticed that the ACE_MMAP_Memory_Pool class provides for the users
> to specify a Semaphore key. However, once I use it via the
> ACE_Malloc<..>::ACE_Malloc(const char* poolname) constructor, I lose
> this option. 

Yes, that is correct.  That design decision was made to keep a clean
interface that will work for all the various types of memory pools.

> Is there any recommended way to specialize ACE classes to allow this
> key to be overridden?

Yes indeed, you just create a new subclass (e.g., class
My_Memory_Pool) that inherits from ACE_MMAP_Memory_Pool and then you
pass in the appropriate key to the constructor of ACE_MMAP_Memory_Pool
in the constructor of My_Memory_Pool.  Then you just say:

typedef ACE_Malloc<My_Memory_Pool, ACE_Process_Mutex> SHMALLOC;

Please check out the file:

examples/Shared_Malloc/Malloc.cpp 

which illustrates more or less how to do this.

----------------------------------------

50.

> What is the best way to turn on TRACE output in ACE.  I commented
> out the #define ACE_NTRACE 1 in config.h and rebuilt ACE and the
> examples.

The best way to do this is to say

#define ACE_NTRACE 0

in config.h.

> When I run the CPP-inserver example in examples/IPC_SAP/SOCK_SAP, I
> get some trace output but not everything I would expect to see.

Can you please let me know what you'd expect to see that you're not
seeing?  Some of the ACE_TRACE macros for the lower-level ACE methods
are commented out to avoid problems with infinite recursion (i.e.,
tracing the ACE_Trace calls...).  I haven't had a chance to go over
all of these indepth, but I know that it should be possible to turn
many of them back on.

> It would be nice to have a runtime option for turning trace on and
> off.

There already is.  In fact, there are two ways to do it.
If you want to control tracing for the entire process, please check
out ACE_Trace::start_tracing() and ACE_Trace::stop_tracing().  

If you want to control tracing on a per-thread basis please take a
look at the ACE_Log_Msg class.  There are methods called
stop_tracing() and start_tracing() that do what you want.

----------------------------------------

51. 

> I've been using an acceptor and a connector in one (OS-) process.
> What does happen, if a signal is sent to this process? Is the signal
> processed by every ACE_Event_Handler (or its descendants) that is
> around?  The manual page simply states that handle signal is called
> as soon as a signal is triggered by the OS.

How this signal is handled depends on several factors:

1. Whether your using ACE_Sig_Handler or ACE_Sig_Handlers to register
   the signal handlers.

2. If you're using ACE_Sig_Handler, then the ACE_Event_Handler * that
   you've most recently registered to handle the signal will
   have it's handle_signal() method called back by the Reactor.

3. If you're using ACE_Sig_Handlers, then all of the ACE_Event_Handler *
   that you've register will be called back.

For examples of how this works, please check out

$ACE_ROOT/examples/Reactor/Misc/test_signals.cpp

This contains a long comment that explains precisely how everything
works!