An Interview with Brian Kernighan (InformIT)

[Posted October 2, 2012 by corbet]

InformIT has an interview with Brian Kernighan, mostly about the C language. "One could argue that Unix's influence on operating systems is easier to assess: aside from Windows in its many variants, most operating systems today are Unix systems. If one counts cellphones, there may well be more *nix systems running than anything else."

to post comments

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 15:05 UTC (Tue) by simlo (guest, #10866) [Link] (23 responses)

One might add that at least one embedded non-unix OS is also heavily inspired by Unix: VxWorks. It is not Unix but I remember it as being much easier to share code between VxWorks and Linux than any of those and Windows.

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 18:27 UTC (Tue) by ballombe (subscriber, #9523) [Link] (22 responses)

On the other hand, counting Mac OS as a unix system is a bit of a stretch. It includes a unix kernel but the Apple frameworks bypass it.

And fork() does not work unless you exec() immediately after, in violation of all unix tradition.

I suppose iOS is still farther from unix.

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 19:33 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

It's a certified UNIX as defined by the Single UNIX Specification.

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 19:57 UTC (Tue) by dskoll (subscriber, #1630) [Link] (20 responses)

And fork() does not work unless you exec() immediately after, in violation of all unix tradition.

Are you sure? This OS X man page looks like the description of the normal UNIX fork.

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 19:58 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Oh, never mind... I missed the CAVEATS section. That's truly broken.

fork

Posted Oct 2, 2012 20:46 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (18 responses)

That's actually a misleadingly titled iOS manual page as far as I can tell.

In terms of actual real world experience rather than linking to poorly labelled online documentation I can report that we never discovered any fork() related problems in our code when the CTO insisted on running it on his OS X laptop for several years. It ran slowly, and it missed various minor features (because OS X lacked the relevant system call or whatever and we had no reason to waste time fixing it just for one guy's laptop even if that guy was the one running the show) but it wasn't any less reliable and there was no sign of fork() being "in violation of all unix tradition"

There are other systems with a fork-like call that doesn't do what fork() actually does, including OS9 and, if we are to judge from that link, iOS but they don't claim to be Unix, let alone UNIX® do they?

fork

Posted Oct 2, 2012 21:00 UTC (Tue) by ballombe (subscriber, #9523) [Link] (11 responses)

The Core foundation framework will actively abort if called after a fork().
This is well documented.

fork

Posted Oct 2, 2012 21:18 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (9 responses)

Needless to say our software (written primarily for Linux, but never deliberately made non-portable) did not use this "Core foundation framework" which judging from its name I'd guess is neither the "core" of the system, nor any sort of "foundation" and possibly not even a framework but instead some layer of crap on the top.

fork

Posted Oct 2, 2012 21:53 UTC (Tue) by ballombe (subscriber, #9523) [Link] (8 responses)

"core foundation" is used by "cocoa" which is the standard GUI library. This is used by e.g. the libfltk "native" port on OS X.
So if you write a portable program that use libfltk as toolkit, then it get linked to "core foundation" on OS X.
So basically GUI^fork.

fork

Posted Oct 3, 2012 0:41 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (7 responses)

> So basically GUI^fork.

That's a common pattern in GUI systems. On Windows, the NT kernel forks just fine --- it's the Win32 subsystem that can't handle it. Under Cygwin, fork works just fine, but the child doesn't inherit any of the Win32 GUI stuff. I honestly don't think of GUI^fork as a major limitation --- why on earth would you want to use the GUI in the child without execing first? How could you coordinate the parent GUI and child GUI?

fork

Posted Oct 3, 2012 12:16 UTC (Wed) by ballombe (subscriber, #9523) [Link] (6 responses)

The parent has no GUI. It produces a set of data for the child. The fork causes the child to get a snapshot of the data. The child displays the data graphically. If the child were to exec() it would lose the data snapshot.

But my point is while there are various UNIX emulation layer available for windows, even one form MS which is POSIX certified, this does not make Windows a UNIX platform. The situation is increasingly similar on OS X.

fork

Posted Oct 3, 2012 17:47 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (3 responses)

> The fork causes the child to get a snapshot of the data. The child displays the data graphically.

Shared memory.

> this does not make Windows a UNIX platform. The situation is increasingly similar on OS X.

Nobody cares about an OS being a "UNIX platform". People care about an OS being able to run useful software. Forking in a GUI program and doing GUI things in the child *just ain't useful*.

fork

Posted Oct 3, 2012 20:37 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

...Shared memory.

What part of "snapshot" is unclear?

fork

Posted Oct 4, 2012 15:28 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

Wouldn't MAP_PRIVATE work for that? (curious, I've never tried)

fork

Posted Oct 4, 2012 19:23 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

MAP_PRIVATE only works once. You can't use it to create multiple versioned snapshots.

fork

Posted Oct 4, 2012 0:41 UTC (Thu) by mpr22 (subscriber, #60784) [Link] (1 responses)

I'm presuming the amount of data involved would be unreasonable to pass over a pipe.

fork

Posted Oct 4, 2012 15:32 UTC (Thu) by bronson (subscriber, #4806) [Link]

Or that it doesn't serialize well, like trees or video processing data.

fork

Posted Oct 2, 2012 21:42 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

The Core Foundation framework isn't part of POSIX, so has no bearing on how UNIX or otherwise an OS is.

fork

Posted Oct 2, 2012 21:01 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (5 responses)

Ah, OK, I found this

https://developer.apple.com/library/mac/#documentation/Da...

It seems that from 10.5 this caveat was added to the official OS X documentation. In that light I think it's safest to conclude that Apple realised fork() is hard (check out the long list of things a current Linux fork does to retain sanity in the face of threads, asynchronous I/O, capabilities and other fun toys that didn't exist at the dawn of Unix) and decided they don't care. It will probably work, but if it doesn't they aren't interested in explaining why/ fixing the problem.

On balance I agree this makes OS X a pretty shoddy Unix, but then, I would have been easily persuaded of that anyway.

fork

Posted Oct 2, 2012 22:51 UTC (Tue) by the.wrong.christian (guest, #73127) [Link] (2 responses)

I'd safely assume that any X11 GUI app that fork'ed then executed GUI calls would suffer from undefined behaviour. Apart from anything else, it'd be sharing an X11 connection with it's parent process, so there would be all sorts of concurrency issues.

I'd wager most libraries are not fork safe, including such libraries as SQLite as mentioned in the SQLite FAQ. Libraries that talk to the outside world contain much state that is not safe to share.

I don't this makes Darwin especially shoddy (this is a Darwin "issue", BTW, rather than an OS X issue.)

fork

Posted Oct 4, 2012 21:06 UTC (Thu) by ballombe (subscriber, #9523) [Link] (1 responses)

> I'd safely assume that any X11 GUI app that fork'ed then executed GUI calls would suffer from undefined behaviour. Apart from anything else, it'd be sharing an X11 connection with it's parent process, so there would be all sorts of concurrency issues.

Fortunately, you are wrong. The X11 protocol allows the child to open its own display and create its own graphic context without interfering with the parent process.

fork

Posted Oct 5, 2012 4:20 UTC (Fri) by Kit (guest, #55925) [Link]

How many applications out there actually take advantage of that ability? I'm fairly certain that sort of exotic thing isn't ever used by either GTK or Qt. X11 has a lot of flexibility that seems to never actually get used for one reason or another.

fork

Posted Oct 4, 2012 21:46 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

It only makes it as shoddy as any other Unix.

The root of the problem is threading, and that exact same problem exists everywhere else. Historically, the behavior when both forking and threading was never well defined. The old rule was, never fork after starting a thread. And this rule still persists, even on systems like Solaris and Linux which actually try hard to make simultaneous forking and threading safe.

Now, if a third-party library starts up threads in the background, then it follows that the application should never fork after entering that library. If the application is linking that library at load-time, at the library initializes itself by starting threads, then technically the application should never, ever call fork.

Presumably, then, it would seem that some of Apple's libraries immediately spin up threads in the background (and/or initialize similar resources which don't behave well with fork). This is nothing new.

fork

Posted Oct 11, 2012 10:10 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, this sort of thing is why pthread_atfork() was invented, so that libraries could hide their threaded implementation from their users. A properly written threaded library should not prevent its callers from forking.

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 15:47 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

"we seem to be spending more of our resources on high-priced arguments about trivial "inventions" than on creating new ones."

This is my suggestion for quote of the week. And maybe of the year.

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 17:47 UTC (Tue) by nachtan (guest, #73227) [Link]

Agreed.

This quote too, is worth seeing again as QoD or QoY

"Governments have perhaps come a bit late to the party, but they too are eager to learn everything possible about their citizens. I fear that without some unlikely combination of restraint, law, and pushback by ordinary people, we are heading to a world that will make the invasions of Orwell's 1984 seem desirable by contrast."

An Interview with Brian Kernighan (InformIT)

Posted Oct 2, 2012 21:37 UTC (Tue) by Julie (guest, #66693) [Link]

Nearly a year to the day since the sad passing of Dennis Ritchie :-(

On a more positive note:

A couple of days ago, I remember seeing a Google promo vid that claimed (as I recall) that most people's first stop on booting a browser was Google Search.

Me, mine is LWN. Without LWN's sharp eyes I would have missed this amongst the churn. So thanks, Jon.

This is a really nice article. Kernighan is one of those true veteran hackers who has never taken his finger off the pulse of things that matter.