Conference clt::cma

.0> How best can I cleanly get thread B to process the cma_e_alerted
.0> exception when it is given, without thread B having to wait
.0> for thread C to enqueue something for it?

What makes you think that thread C has to enqueue something in order for 
thread B to receive the alert?  Unless thread B has alerts disabled, the alert
should awaken thread B as soon as it is sent, and thread B should (more or less)
immediately receive the alerted exception.


				Webb

        But cma_lib_queue_dequeue is not a cancelation point...
        
        Section 2.7 "Thread Cancelation" of the March 1994 Guide to
        DECthreads lists the cancelation points and it isn't in the
        list; its individual man page mentions nothing of being a
        cancelation point either.
        
        Is it safe to call cma_alert_enable_asynch() immediately before
        cma_lib_queue_dequeue() and cma_alert_disable_asynch()
        immediately after?
        
        Or are you saying the documentation is incomplete and
        cma_lib_queue_dequeue() really is a cancelation point?
        
        Dan

>        But cma_lib_queue_dequeue is not a cancelation point...
>        
>        Section 2.7 "Thread Cancelation" of the March 1994 Guide to
>        DECthreads lists the cancelation points and it isn't in the
>        list; its individual man page mentions nothing of being a
>        cancelation point either.

The cma_lib_ routines aren't "first class citizens" -- they're not part of
POSIX, DCE threads, or CMA. They're add-ons. Therefore they're not listed in
the (architectural) list of cancellation points.

The individual routine descriptions probably should have pointed out which
are cancellation points -- but this is moot now, since the most recent
published version of the manual no longer includes the CMA, CMA_LIB, or DCE
thread functions, and they won't be restored.

In fact, cma_lib_queue_dequeue is a cancellation point, so "'ave at it."

>        Is it safe to call cma_alert_enable_asynch() immediately before
>        cma_lib_queue_dequeue() and cma_alert_disable_asynch()
>        immediately after?
 
Never. NO functions in DECthreads are async cancel safe except the functions
that disable async cancellation! And don't count on any other functions,
anywhere, ever, being async cancel safe.
       
>        Or are you saying the documentation is incomplete and
>        cma_lib_queue_dequeue() really is a cancelation point?

Yes. As I said, there is no reasonable way to address this omission at the
current time. And since you're the first one in 7 years or so to even ask, I
expect it'll not cause many people much difficulty.

	Thanks!  That makes this change so much easier! :-)
        
        The loop had been controlling when a cancelation could
        occur, and in fact there was such a test just before
        dequeueing from the queue:
        
            cma_alert_enable_general(&alert_state);
            cma_alert_test();
            cma_alert_disable_general(&alert_state);
        
            cma_lib_queue_dequeue(&queue, &addr);
        
        So I changed the above to:
        
            cma_alert_enable_general(&alert_state);
            cma_alert_test();
            cma_lib_queue_dequeue(&queue, &addr);
            cma_alert_disable_general(&alert_state);
        
        and now it does immediately process the cma_e_alerted exception.
        
        Dan