| 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(). |
| maintained by bob@werken.com | |