ACE Frequently Made Mistakes

symptom | ACE_Task::getq() returns the error resource temporarily unavailable
probable cause | Your Task is a subclass of ACE_Task<ACE_NULL_SYNCH> and you are using it in a multithreaded program.
solution | Try using ACE_Task<ACE_MT_SYNCH> instead so that the associated Message_Queue is configured for access by multiple threads.
symptom | ACE_Task::wait() throws an assert violation
probable cause | When you activate()d your Task, you specified THR_DETACHED, which causes wait() to be unable to perform what you want it to.
solution | Make sure you specify the flag THR_JOINABLE when activating your ACE_Task object.
symptom | Apparent race conditions when spawning threads (or activating Tasks) from within a constructor.
probable cause | You are not guaranteed to have a valid this pointer until the constructor has exited. Threads spawned from a constructor are free to run immediately, and may attempt to use an invalid this pointer.
solution | Move your Task activations and other thread-spawning activites out of the constructor.
symptom | Compiler issues warnings/erros regarding using too few template arguments, such as "'ACE_Svc_Handler' : too few template arguments".
probable cause | Instead of using the appropriate macro, you supplied an actual class name as a parameter. This will fail depending upon platform and compiler, due to the way templates are handled.
solution | Instead of instantiating a template class like ACE_Svc_Handler<ACE_SOCK_Stream, ACE_NULL_SYNCH>, use the form of ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_NULL_SYNCH> which circumvents the platform peculiarities by using the macro. This also applies to some other template classes.
symptom | Unable to compare ACE_thread_t variables (such as ACE_Thread::self()) using operator== ().
probable cause | On some platforms, thread ids are numeric, and on some, they aren't. On some implementations, simple a == b comparisons are legal and sane. Some are not.
solution | Use the ACE_OS::thr_equal() function to reliably compare thread ids, regardless of platform.
symptom | ACE_Reactor::run_event_loop() does not seem to function correctly for a Reactor created in your application.
probable cause | You have not set the ACE_Reactor::instance() to refer to your new reactor. run_event_loop only functions on the reactor currently installed as the global Singleton.
solution | Use the ACE_Reactor::instance(ACE_Reactor *, int delete_reactor = 0) static method to install your reactor as the global Singleton before calling run_event_loop().
symptom | Infinite recursion when you invoke ACE_Reactor::remove_handler()
probable cause | You are invoking remove_handler() from within handle_close() (or a method invoked by handle_close()) but you have not specified the DONT_CALL flag.
solution | Be sure to OR in the DONT_CALL flag in this situation. e.g. --
    int MyHandler::handle_close (ACE_HANDLE handle,
                                 ACE_Reactor_Mask close_mask)
    {
        ...
        my_reactor_->remove_handler( this,
                                    ACE_Event_Handler::READ_MASK |
                                    ACE_Event_Handler::DONT_CALL );
        ...
        return 0;
    }
maintained by bob@werken.com

Back to ACE Documentation Home.