[mod.os.unix] Unix Technical Digest V3 #3

usenet@cuae2.UUCP (Heiby) (02/05/86)

Unix Technical Digest       Wed,  5 Feb 86       Volume  3 : Issue   3

Today's Topics:
                              Correction
                   IPC interface for 4.2BSD & SysV.
       Kernighan & Pike's example of signal use: is it correct?
                 Sibling lists in 4.2 proc structure
----------------------------------------------------------------------

Date: Wed, 29 Jan 86 18:20:47 est
From: hcr!lsuc!dciem!msb
Subject: Correction

[Sorry about that!  RWH]

> mail `grep ":$" /etc/passwd |	# everyone with the shell; you might want
> 				# to grep for csh too if it's relevant.
> sed 's/.*//'`			# Cut it down to just the login name
> 
> [Ed note: Thanks to Mark Brader for a correction to the above.  RWH]

Um, I hate to seem picky, but if you're going to thank me for the
correction, you might run the corrected version!  Once more: ":$" should
be ':$' and .* should be :.* and THEN it should work.

You don't need to use both grep and sed anyway.  You can say
	mail `sed -n '/:$/s/:.*//p' /etc/passwd`

Mark Brader - ihnp4!utzoo!{dciem,lsuc}!msb
I AM picky.  I just hate to SEEM picky.

------------------------------

Date: Mon, 3 Feb 86 17:17:51 GMT
From: jrp@nplmg1a.uucp
Subject: IPC interface for 4.2BSD & SysV.

We need to implement  a system consisting of  a number of  communicating
processes.  The requirement is to be able to  run this under both System
V.[02]  and Berkeley 4.2BSD UNIX.

The most promising solution  would appear to be  to define a library  of
high-level communication primitives that could be implemented under both
varieties of UNIX.

Has anyone defined such a set of primitives? Has anyone implemented such
a set?  I look forward to hearing from you if you have,

------------------------------

Date: Mon, 27 Jan 86 18:32:56 est
From: Kevin Szabo <ihnp4!watmath!watvlsi!ksbszabo>
Subject: Kernighan & Pike's example of signal use: is it correct?

[There was some discussion of signals and stdio reentrancy a while back,
but perhaps this message will generate some new information.  RWH]

On Page 227 of `The Unix Programming Environment` the
following example of `correct' signal handling is given:

#include	<signal.h>
#include	<setjmp.h>
jmp_buf sjbuf;

main()
{
	int onitr();

	if (signal(SIGINT, SIG_IGN) != SIG_IGN)
		signal( SIGINT, onintr );

	setjmp( sjbuf );

	for(;;) {
		/* main processing loop */
	}
}

onintr()
{
	signal( SIGINT, onintr );
	printf("\nInterrupt\n");
	longjmp(sjbuf, 0);
}


It is my impression that you cannot do anything significant
within a signal handler, including printing information such
as `Interrupt`.  K&P mention in later paragraphs that
routines which update data-structures should not be
interrupted; in this case the interrupt catcher should just
set a flag.  However, does not printf, and most library
routines, do some updating of data structures?  All
implementations of STDIO that I have seen manage some form
of buffer, usually obtained by MALLOC.  MALLOC certainly is
not re-entrant.

So -- is there a problem with the example?  Or is there a
problem with implementations of STDIO?  Or is there no
problem whatsoever?

			Kevin

Kevin Szabo' watmath!watvlsi!ksbszabo (U of W VLSI Group, Waterloo, Ont, Canada)

------------------------------

Date: 30 Jan 86 19:19:01 +1100 (Thu)
From: Robert Elz <seismo!munnari!kre>
Subject: Sibling lists in 4.2 proc structure

[I think I lost a message on this topic.  Sorry.  If there was
information in it not covered here, please re-submit it.  RWH.]

They aren't used in 4.2 - I added them just so they could sit
there and be manipulated, and make sure that they were being
correctly maintained, before they actually started being used.

In 4.3, they are used as you would expect, the wait() sys call
runs about 10 times faster (depends on how many children the
waiting process actually has), with similar speedups in the
related sys calls (fork() and exit() are also considerably quicker).

Speeding up these sys calls might seem a little exotic - but measurements
here showed them to be consuming signifigant amounts of kernel time,
way more than I had anticipated.  They don't any more.

Robert Elz		seismo!munnari!kre   kre%munnari.oz@seismo.css.gov

------------------------------

End of Unix Technical Digest
******************************
-- 
Ron Heiby {NAC|ihnp4}!cuae2!usenet   Moderator: mod.newprod & mod.os.unix
AT&T-IS, /app/eng, Lisle, IL	(312) 810-6109