Subject: FVWM CVS: fvwm domivogt

From: CVS <[email-masked]>
Date: Sun, 27 Dec 1998 17:27:40 -0600 (CST)

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	98/12/27 17:27:39

Modified files:
	.              : ChangeLog NEWS configure configure.in 
	docs           : Makefile.in 
	extras         : Makefile.in 
	extras/FvwmCommand: Makefile.in 
	extras/FvwmConfig: Makefile.in 
	extras/FvwmConsole: Makefile.in 
	extras/FvwmDebug: Makefile.in 
	extras/FvwmGoodStuff: Makefile.in 
	extras/FvwmPipe: Makefile.in 
	extras/FvwmScript: Makefile.in 
	extras/FvwmScript/Scripts: Makefile.in 
	extras/FvwmScript/Scripts/some_nice_icons: Makefile.in 
	extras/FvwmScript/Widgets: Makefile.in 
	extras/FvwmTaskBar: Makefile.in 
	extras/FvwmWharf: Makefile.in 
	icons          : Makefile.in 
	libs           : Makefile.in Parse.c 
	modules        : ChangeLog Makefile.in 
	modules/FvwmAnimate: Makefile.in 
	modules/FvwmAudio: Makefile.in 
	modules/FvwmAuto: Makefile.in 
	modules/FvwmBacker: Makefile.in 
	modules/FvwmBanner: Makefile.in 
	modules/FvwmButtons: FvwmButtons.1 FvwmButtons.c Makefile.in 
	                     parse.c 
	modules/FvwmCpp: Makefile.in 
	modules/FvwmEvent: Makefile.in 
	modules/FvwmForm: Makefile.in 
	modules/FvwmIconBox: Makefile.in 
	modules/FvwmIconMan: Makefile.in 
	modules/FvwmIdent: Makefile.in 
	modules/FvwmM4 : Makefile.in 
	modules/FvwmPager: Makefile.in 
	modules/FvwmRearrange: Makefile.in 
	modules/FvwmSave: Makefile.in 
	modules/FvwmSaveDesk: Makefile.in 
	modules/FvwmScroll: Makefile.in 
	modules/FvwmTalk: Makefile.in 
	modules/FvwmWinList: Makefile.in 
	sample.fvwmrc  : Makefile.in 
	utils          : Makefile.in 
	xpmroot        : Makefile.in 

Log message:
applied FvemIconMan signal handling patch (already ast CVS session)
FvwmButtons geometry bugfix
Fixed bug #97 (multiple quotes needed in FvwmButtons)
FvwmButtons: no more need to quote Action
Fixed coredump in libs/Parse.c (SkipQuote).
set version to 2.1.7
this should be the last time all the Makefile.in's get updated

--
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: Chris Rankin <[email-masked]>
Date: Mon, 28 Dec 1998 01:40:22 +0000

> applied FvemIconMan signal handling patch (already ast CVS session)

I have just checked the new FvwmIconMan.c and it's still using the wrong
signal handling - I revised the signal handling just over a week ago
when I became dissatisfied with the reentrancy of siglongjmp(). As a
result, I posted a collection of patches which applied the following
signal scheme:

int TerminateHandler(int nonsense)
{
  isTerminated = True;
}

int event_loop(void)
{
  while ( !isTerminated )
  {
    ... get event ...
    ... process event ...
  }
}

Do you have those patches? I'm afraid that I can't repost them until at
least next week because they're on a different hard disc.

Cheers,
Chris.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 06:12:43 +0100

> least next week because they're on a different hard disc.

Same with me. If you can send them to my private address again
(see signature) I can apply them. Otherwise it will probably have
to wait until January.

Bye

Dominik

-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Mon, 28 Dec 1998 15:49:52 -0500

> (see signature) I can apply them. Otherwise it will probably have

Were the portability issues of these changes ever addressed?

I  seem  to recall   the very good  suggestion  of   using emacs  as a
reference implementation  for signal handling.   I don't recall anyone
coming up with a better idea, or reporting what emacs does.

Is there a reason to include any of this in 2.2?

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
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: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 23:12:15 +0100

> Were the portability issues of these changes ever addressed?

I think they were addressed, but I'm not sure what the outcome was.
 
> Is there a reason to include any of this in 2.2?

They are already in. We're talking about updates at the
moment. Personally I am willing to take the risk of breaking
a *few* exotic systems in 2.2. As far as I understand Chris
has worked a bit on this portability issue so I'm not too
worried about that. The alternative is to back out this
signal handling stuff again and get some fvwm crashes in
return.

Bye

Dominik

---

From: Chris Rankin <[email-masked]>
Date: Tue, 29 Dec 1998 00:04:52 +0000

> I think they were addressed, but I'm not sure what the outcome was.

To be precise, I posted a request on comp.unix.programmer for anyone
without POSIX.1 signal-handling to "come forth" and say what they DID
have available. I had one reply saying that maybe SVR3 systems met this
dubious requirement, and that the lowest common denominator of all UNIX
signal handling was the obselete "signal" function and not much else.
Trying to make ANYTHING signal-safe on such a system would (IMHO) be
like trying to give a dodo flying lessons.

Dan Espen wrote:
> reference implementation  for signal handling.

Actually, it was samba. I have been studying the samba code and they use
signal() rather than sigaction(), trying to account for all of
signal()'s broken and different semantics. However, they do try to use
POSIX.1 and BSD4.3 features if they are available. They also use some
blatantly non-reentrant functions in their clean-up handlers, but then
maybe they know their code intimately and so KNOW that this will never
cause a problem...?

I have worked out a POSIX.1 scheme for fortifying the FVWM signal
handling. I believe that I can port this scheme to BSD4.3 providing BSD
provides a longjmp() function (I won't need siglongjmp() because I will
be restoring the process's signal mask manually). Hopefully both POSIX
and BSD provide sigaction() because signal() is a complete mess.

Ultimately, I think we should aim for POSIX.1 but cater for BSD. Any
system which supports neither would get my vote for being "exotic".

> Is there a reason to include any of this in 2.2?

Bugs Are Baaaad. Bugs Are Baaaad ... ;-) !

Cheers,
Chris.

---

From: "Josh M. Osborne" <[email-masked]>
Date: Tue, 29 Dec 1998 17:19:09 -0500

>On Mon, Dec 28, 1998 at 03:49:52PM -0500, Dan Espen wrote:
[...]
>and BSD provide sigaction() because signal() is a complete mess.

There is a longjmp() in 2.11BSD :-)
And 4.3Net/2, and 4.3 RENO, and 4.3 Lite2.  (I had to search them
for "setjmp").  Ah, wait there it's in V7.  That ought to leave it
*everywhere*

I think I clipped some part of the message that asked about sigaction,
which 4.3Net/2 has.  See http://www.freebsd.org/cgi/man.cgi?query=sigaction&apropos=0&sektion=0&manpath=4.3BSD+NET%2F2&format=html
(you can get the man pages for many systems there)

>system which supports neither would get my vote for being "exotic".

Sounds good to me.

[...]