ACE FAQ

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 INSTALL 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.

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++. This has been done successfully for GCC 2.7.1 on Solaris 2.x. We're working on making this work on other platforms GCC has been ported to.

BUILD	= $(VSHLIB) $(SHLIBA)

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;
}

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."

Note that the return values of 0 and < 0 are by far the most common cases -- > 0 is only used for unusual circumstances.

./include/config-sunos5-sunc++-4.x
./include/makeinclude/platform_sunos5_sunc++.GNU

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:

• 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.gz). 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.

• 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.

• 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.

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

• 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

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

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

    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).
    }

    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_;
    };

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 ();

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

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;

examples/Shared_Malloc/Malloc.cpp 

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.

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

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