Subject: FW: FVWM: Signal handling

From: "Rankin, Chris" <[email-masked]>
Date: Fri, 8 Jan 1999 13:48:26 -0500

Hi Paul (PDS),
This email bounced from your [email-masked] address with the
following error:

   ----- The following addresses had permanent fatal errors -----
psmith@engeast
    (expanded from: <[email-masked]>)

   ----- Transcript of session follows -----
554 MX list for mailhost.baynetworks.com points back to
smtp-gw.BayNetworks.COM
554 psmith@engeast... Local configuration error

Chris.

> ----------
> From: 	Rankin, Chris
> Sent: 	Friday, January 08, 1999 1:44 PM
> To: 	[email-masked]'
> Subject: 	RE: FVWM: Signal handling 
> 
> 	Hi,
> 	Thoughts ... hmmm ... 
> 
> 	Well, the design was "just use the signal handler to set a
> terminatation flag, then make the event loop end when this flag becomes
> true". This approach is pretty minimalist, but it's self-defeating to try
> to
> do much more in a signal handler. It should also be the most portable way
> of
> doing things.
> 
> 	The current implementation also has those race conditions I
> described, but I'll leave that for now.
> 
> 	The intent of the USE_POSIX and USE_BSD #defines was to avoid the
> fuzzy, platform-dependent semantics implied by the signal() function by
> using sigaction() where available, but imposing BSD semantics otherwise.
> BSD
> semantics are nice because they do safe, sensible things like masking a
> signal while its handler is running, keeping the signal handler installed
> and restarting certain system functions if they are interrupted.
> 
> 	At the moment, the POSIX.1 implementation requires:
> 	sigaction()
> 	struct sigaction
> 	sigset_t
> 	sigemptyset()
> 	sig_atomic_t (ahem!)
> 
> 	The BSD implementation *should* require:
> 	signal()
> 	siginterrupt() - (it doesn't use this at the moment: I should really
> call siginterrupt() after every signal() call that sigaction() installs as
> SA_INTERRUPT)
> 	sig_atomic_t
> 
> 	All the signal handlers at the moment do is to set global data
> atomically, so I haven't done anything with signal masks yet. It doesn't
> matter if two different signals call the same handler function at the same
> time. This will change later when I use setjmp()/longjmp() to remove the
> race. At that time, I will also require:
> 
> 	POSIX.1
> 	sigprocmask()
> 	sigaddset()
> 
> 	BSD:
> 	sigblock()
> 	sigsetmask()  - these two replace sigprocmask()
> 	sigmask()      - this replaces sigaddset()
> 
> 	There is also the nasty little wrinkle that sigset_t is POSIX.1 and
> is not in BSD.
> 
> 	I know I'm going to regret asking this, but what is/isn't available
> on SunOS 4? You don't also have a SunOS 3 machine, do you (shudder)?
> 
> 	Cheers,
> 	Chris.
> 
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Jason L Tibbitts III <[email-masked]>
Date: 08 Jan 1999 13:14:06 -0600

Note that Paul's (well, really Bay Networks') mail servers are hosed.  More
specifically, at least one of them is, but at least one is not because some
mail gets through.

 - J<