Conference bulova::decw_jan-89_to_nov-90

    Xlib is not 100% signal safe.  UNIX signals are heavyweight and
    protecting against them in Xlib is too expensive.  You can use signals
    safely if you do not make Xlib calls in your signal handlers.  If you
    must make Xlib calls in the signal handlers, you must be sure that all
    the Xlib queues are empty before you make the call.  Alternatively, you
    can block signals when the queues are not empty.
    
    One alternative is to use two Xlib connections, one for normal use and
    the other for your signal handlers (assuming that signals will not
    interupt each other).
    
    Another possibility is to use the timer and file descriptor handlers in
    the X Toolkit.  These mess with select() instead of signals.
    
    Ken
    

    If Xlib isn't signal safe, how to we solve the problem raised in notes
    693, 1001, and 1292.
    
    TPU has to ensure that it dispatches events in a timely fashion.  To do
    this even then the TPU application is busy in a long operation (perhaps
    even an infinite loop), TPU has a timer go off every second.  When the
    timer goes off, TPU sets some flags and sends itself a client message. 
    After the timer handler returns the TPU interpreter notices that the
    flags are set and dispatches events.  When it has dispatched all the
    events, it goes back to processing the long operation.
    
                                    August G. Reinig

    Like I said, there are several ways to safely use signals with Xlib.
    You may want to talk to the PHIGS people, who have an architecture
    similar to yours and are using signals successfully.
    
    Ken
    

    I talked to Barry Tannenbaum.  From what he suggested, here's what I'm
    doing:
    
    At startup, on ULTRIX:
    
        env [decw_a_display] = DwtGetDisplay (.env [decw_a_top_widget]);
    	env [decw_a_display2]
	    = XOpenDisplay( XDisplayString (.env [decw_a_display]));

    (Does anyone know if the string returned by XDisplayString has to be
     freed?  The documentation didn't say.)
    
    At signal level, to send a client message to ourselves:
    
        event [x$l_clnt_type] = x$c_client_message;
        event [x$a_clnt_display] = .env [decw_a_display];
        event [x$l_clnt_window] = .env [decw_a_main_window];
        event [x$l_clnt_message_type] = x$c_none;
        event [x$l_clnt_format] = 32;

        !
        ! Send the event - Note that the event mask is bogus.  This is the value
        ! that the session manager uses, and 0 causes a fatal XLIB error
        !
        XSendEvent (.env [decw_a_display2],		! Display2  <=======
		    .env [decw_a_main_window],	! Window
		    false,			! Don't Propagate
		    x$c_client_message,		! Event Mask
		    event [$address]);		! Event
        XFlush (.env [decw_a_display2]);
    
    Also, where ever we have code that uses XEventsQueued to find out the
    number of events queued up we have to check both decw_a_display and
    decw_a_display2.
    
    I hope that this works.
    
                                            August G. Reinig
    
    
    
    

>>    (Does anyone know if the string returned by XDisplayString has to be
>>     freed?  The documentation didn't say.)

Do not free this string.  XDisplayString "calls" the DisplayString macro:

	#define DisplayString(dpy)      ((dpy)->display_name)

-steve-