| The real problem is that the XUI toolkit isn't reentrant and also is not
prepared to be unwound out of (which is what longjump does). There are ways
around this problem (establishing a condition handler to clean up on unwind),
but the Xt developers apparently either didn't know about or didn't care
about modular programming p practices, so the Toolkit doesn't handle this
situation. A pity.
--PSW
|
| RE.0
I am not an very fluent in VAX C but C is C..right?
Are you sure the error recovery routine is properly written?
For an accurate backtracking to take place between the setjmp and
longjmp routines, the function that first invoked setjmp must not
itself have returned in the interim. After the longjmp operation,
all accessible data have values as of the time when longjmp was
called.
Does the customer's setjmp/longjmp routine look anything like this?
[Sorry if the example doesn't speak enuff VMS venacular like
"ACCVIO and INVOPERAND" :-)... just trying to help...]
[...include X....relevant header files..]
jmp-buf stk;
main()
{ /* init and set up things here */
if (setjmp (stk) !=0)
{/* any adjustments after recovery */
}
other(...);
}
other()
{ ...
/* when error is detected and recovery desired */
recover(errno);
....
}
void recover(e)
int e;
{/* adjust values of variables if needed */
longjmp(stk,e);
}
The longjmp (when called with a saved 'stk' and an integer 'e', will
normally restore the saved stack environment ('stk') and cause
execution to resume as if the original setjmp call has returned
the value 'e'. Clear as sea weed? :-)
So, please check the C program again before dismissing Xt as the culprit.
Please, I am not suggesting that Paul's comments are not true.
The C language is known to act very strange when it comes to error handling.
Kris..
|
| Thanks for the help.I have suggest to my customer your idea, and
his answer was the following:
'Your basic structure is correct for a normal program.And I am pretty
sure we dont ivalidate any of our jmp_buf's.OUr program is fully
recursive interpreter, but I'll try to give a simplistic view...
The basic structure has worked for years, its only the going through
a callback routine thats given us a few problems.
main()
initialise();
interpret();
closedown;
interpret();
[
jmp_buf env;
setjmp (env) ;
pushframe(&env) ;/* an internal stacking process-see unwindframe...*/
while (TRUE)
[
if ( XQLenght () > 1) [ getevent5) ; dispatchevent() ]
/* above stops X Q overfilling if we are compute bound. */
...interpret the program...
one possibility is invoked_a_window();
...one "error" use an unwindframe() which works back up ...
possibly more than 1 level at time.
]
]
invoke_a_window ()
[
int still_going =TRUE;
set up and register my_callback and &still_going
declare widgets etc.
while ( still_going ) [ get_event(); dispatch_event(); ]
]
my_callback()
[
switch on event;
terminate :*p_still_going = FALSE ;
recurse : interpret() ; /* >>>>> this is the fun starts*/
]
This is all brave stuff, I do not recommend this programming style
to the unwary.I cannot give any more detail for confidentiality
reasons.'
That's my customer answer.Could someone help me to answer him.
Thanks you very much and best regards
Maya
|
| RE .0
>Should he uses VAX conditions handlers?via
>VAXC$ESTABLISH and try to avoid UNIX emulation?Is the problem inherent
>to X lib, X tollkit or DECWindows layers?
Here is some interesting discussion on a related topic (X signal handling)
that I came across on the Usenet.
I hope it sheds some light on a much bigger problem.
Kris..
"
From: [email protected] (Nick Maclaren)
Newsgroups: comp.windows.x
Subject: Re: Handling signals in X (was: Reading sockets from the Toolkit)
Message-ID: <[email protected]>
Date: 17 May 89 09:53:01 GMT
References: <[email protected]> <[email protected]> <[email protected]
Sender: [email protected]
Reply-To: [email protected] (Nick Maclaren)
Organization: U of Cambridge Comp Lab, UK
Lines: 31
Posted: Wed May 17 10:53:01 1989
[email protected] (Dan Heller) writes:
> Both X and the intrinsics need to handle -all- signals intelligently, or
> disaster is definitely awaiting. ....
I agree, but Chris D. Peterson is also right about the fact that not everyone
has UNIX. I am afraid that designing this area is EXTREMELY nasty and there
are very few people in the world with the requisite skills. Yes, it needs
to be done, but it must be done extremely carefully and with great attention
paid to getting as wide a range of input as possible.
For example, there are 4 'ANSI' C compilers for IBM MVS, which is about as
different from UNIX as you can hope to achieve. Only one of these (the one
I wrote!) supports longjmp from out of a SIGINT handler called from within
I/O (e.g. waiting for terminal input). Whether this can be done is clearly
critical to the design of the X signal handling.
The ANSI C description of signal handling is about as portable as anything
I have seen that is flexible enough to use. However, there are a good many
aspects of its design that are severely system-dependent, and cannot be done
on systems that use an exception model that is radically different from the
UNIX one. I could go into details, but I don't think this forum is
appropriate.
The X Consortium are quite right to have stayed out of this minefield so far,
even though it needs to be crossed at some stage.
Nick Maclaren
University of Cambridge Computer Laboratory
nmm @ cl.cam.ac.uk
"
|