Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Solaris Systems Programming

timothy posted more than 9 years ago | from the solaris-system-alignment dept.

Sun Microsystems 181

Ben Rockwood writes "UNIX, in all its many forms, was developed by developers for developers. This is evident in the connection between UNIX and C. In many ways, you can't truly understand one without the other. Certainly, there are plenty of UNIX users and admins who understand semaphores but have never written a threaded application, and C programmers who have never left the Windows world, but nevertheless at some point you'll encounter the symbiotic relationship the two share. Often, though, we find system administration books that discuss programming topics but not programming itself -- and conversely, C programming books that don't address the essence of UNIX. When we combine the two topics we get a systems programming book, an epic guide that clarifies relationships essential to understanding both entities in a truly holistic manner." Read on for Rockwood's review of Solaris Systems Programming, a book he describes as reaching this ideal.

Several such guides have popped up over the years, such as The UNIX Programming Environment (Kernighan & Pike 84), Advanced UNIX Programming (Rochkind 85), The Magic Garden Explained (Goodheart & Cox 94), Advanced UNIX Programming (Gay 00) (that's not a typo, there really are two books with the same name), UNIX Systems Programming (Robbins & Robbins 03), UNIX Systems Programming for SVR4 (Curry 96), and the undisputed heavyweight champ, Advanced Programming in the UNIX Environment (Stevens 92).

Each of these books is distinctive, yet they share a number of topics. Essential topics include low- and high-level IO, signal handling, processes, IPC, and basic file system mechanics. In the more modern books, we see the inclusion of popular topics such as threading. Discussion directed toward broader topics of UNIX vary widely, namely due to the OS agnostic nature of such guides, despite the fact that until recently many books tended to slant toward SunOS/Solaris. Regardless of how many systems programming texts have appear, however, most programmers will agree that Stevens' guide is the only truly definitive choice. Since its release, there has been little challenge to its prominence, despite the emergence of Linux as a major UNIX implementation, despite several newer systems programming books, and even the 2nd edition of Rochkind's guide. But all of this now changes thanks to the release of Rich Teer's Solaris Systems Programming.

At a whopping 1248 pages, this volume dwarfs just about every systems programming book available by over 500 pages. It avoids the distractions of OS ambivalence by being tailored to Solaris, but is applicable to any UNIX platform available including Linux. Its layout is similar to that of Stevens' or Curry's books but builds significantly on each topic.

New systems programmers will immediately appreciate Teer's completeness, both in topic coverage and in his example code. Almost every code example is complete and runnable, unlike many of the other guides that demonstrate a topic only in an abstract function rather than complete program. Essential topics for completeness which have remained surprisingly absent from nearly every guide available (such as memory, code security and 64-bit topics) are thoroughly covered. A striking example is coverage of memory topics. When I pulled volume after volume off the shelf of my local bookstore and looked up "memory" in the index of each, I found surprisingly few even cover the topic beyond explaining the difference between stack and heap. In fact, many don't even include the malloc() function. Solaris Systems Programming is the only book I've ever found so complete in its memory discussion that it not only covered stack and heap, all the available memory management functions, but even discusses such important topics as memory alignment!

A complete chapter on secure C programming is provided, thoroughly discussing such important topics as buffer overflows, chroot jails, and program environment. A good number of tips are provided to help you immediately incorporate better security into your app whether it's a real concern (for now) or not. Combine this with a complete chapter on resource control and limits, including discussions on system information, the /proc file system, and some Solaris-specific resource control facilities, you can write more intelligent, less obtrusive, and better-tuned applications.

The coverage of advanced IO topics (including STREAMS) and file system coverage are superior to that in any other text I've seen. System admins will appreciate the in-depth coverage of file system topics that have only seen this sort of detail in books such as Solaris Internals (Mauro & McDougall, 00). This level of discussion allows not only a better understanding of file system and IO techniques, but also the clarity to immediately start building your own tools that allow you to interact with file system with far greater precision than ever before. Other topics, such as memory mapped IO, have rarely seen such detailed coverage.

A full treatment of IPC topics are handled, but like Stevens', these techniques are discussed using conventional concurrency techniques such as fork(). A discussion of POSIX threading is absent and regarded as too large a topic to address properly in a systems programming book and the reader is urged to consult a complete guide to the topic such as Programming with POSIX Threads (Butenhof, 97). While some readers might be put off by this, you'll appreciate how this keeps IPC discussions unencumbered. POSIX threading is mentioned where applicable, so it's not at all ignored, but readers of Rochkind's 2nd Edition or Robbins' books will notice that introduction of a PThreads overview can quickly overwhelm the rest of the text. Unique to any other text with which I am familiar is the inclusion of a section on Solaris Doors (also applicable to the Linux implementation), which is the fastest IPC method in Solaris, introduced with Solaris 2.6.

Something that both new and seasoned programmers will appreciate is the inclusion of a chapter on utility functions, and another on localization. The utility chapter provides great a discussion of (and reference to) the often-used functions that many other books ignore, such as string handling and manipulation functions, memory management, byte arrays, temporary files, error reporting, command-line argument parsing, character classes and more. While it's true that these aren't strictly systems programming topics, they are inevitably going to be topics of interest to most programmers. It is the inclusion of such topics that allows you to take your pile of reference books and replace it with this single volume.

A major topic to systems programmers today is 64-bit programming. Naturally, Solaris is a robust 64-bit environment, and is well handled in this book. programmers new to 64-bit environments, whether on Linux, Solaris, or other UNIX platforms, will greatly appreciate the gentle introduction to 64-bit coding, as well as best-practice techniques and sprinkled 64-bit wisdom throughout the text.

Like it or not, Solaris is the dominant commercial UNIX platform in the market today and will be for the foreseeable future. This guide doesn't pull any punches in giving you the best information available to exploit that environment to its full potential. If you're a programmer, this book gives you a single reference to consolidate your library and give you a new appreciation for familiar topics and entry point to things that you might have never leveraged before (Doors, 64-bit optimization, etc). If you're a system admin, you'll find a whole new appreciation for Solaris and UNIX in general with unparalleled understanding of how they really work under the covers, especially if you've already read Solaris Internals. Everyone will love the detail and completeness, combined with with the hundreds of tips (not to mention nifty Solaris trivia) scattered throughout the book. Rich's style is compelling and relaxed, very readable in front of your keyboard or with a cup of coffee on the porch. And readers will enjoy his sense of humor, which is admittedly subtle; experienced programmers and system admins, though, will enjoy the book's wit.

Finally, given the impending release of Solaris 10, yet another aspect of this book needs to be considered: it's an essential companion for DTrace users! Rich couldn't have possibly foreseen this need when he started writing the book, but it is extremely important today. Solaris 10 provides more visibility and debugging tools than any other UNIX system in existence today, the most popular of which is DTrace. But all of these tools expect the user to have a certain level of understanding of the system itself. This book should be standard issue for any sysadmin that ever plays with Solaris 10. When doing system root-cause analysis with DTrace, this book becomes an essential reference, especially if you are allergic to system headers. If you have been using DTrace and getting lost, or feel that you just don't know Solaris the way you need to, buy this book and you'll find the confidence and skills to get you back on track.


You can learn more about Solaris Systems Programming on Rich Teer's home page for the book. On that page the full contents and index are available, including a sample chapter (Ch 8 "System Information and Resource Limits," 62 pages!). You can also visit Teer's personal home page to learn more about him and his work. You can purchase Solaris Systems Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

181 comments

Sorry! There are no comments related to the filter you selected.

Nothing. (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10507775)

Nothing for you to see here. Please move along.

this reminds me of (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10507777)

http://home.pacbell.net/ericbear/pics.html

yy (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10507791)

i hate books

Dougla Adams (5, Funny)

Anonymous Coward | more than 9 years ago | (#10507796)

Am I the only one that can't read the word holistic without thinking about electric monks on horses?

Re:Dougla Adams (1)

spuzzzzzzz (807185) | more than 9 years ago | (#10508438)

I tend to think more of lost cats in Bermuda, personally.

6 year old view of the computer world (1, Interesting)

Rosco P. Coltrane (209368) | more than 9 years ago | (#10507818)

Certainly, there are plenty of UNIX users and admins who understand semaphores but have never written a threaded application, and C programmers who have never left the Windows world,

Newsflash: Windows implements IPC mechanisms. You know, like all modern multitasking OSes?

Other newsflash: C programmers can be found under Windows, Unix, MacOS10, BeOS, GEM, ThingamabobOS... In fact, real professional programmers can program in anything under any environment, they just happen to be a bit more proficient under certain kinds of environments.

Re:6 year old view of the computer world (3, Informative)

agent dero (680753) | more than 9 years ago | (#10507852)

Third newsflash: there are many things that you can only really do with C on Unix systems, POSIX anybody?

Re:6 year old view of the computer world (3, Insightful)

Kiryat Malachi (177258) | more than 9 years ago | (#10507879)

There are many things you can only do with C compiled directly to the core on an embedded system, effectively writing your own OS. This does not make programming to the raw iron any better than UNIX or even Windows, just different.

Re:6 year old view of the computer world (0)

noselasd (594905) | more than 9 years ago | (#10507882)

What about it ? services for unix from MS contains a posix subsystem, and we have cygwin.

Re:6 year old view of the computer world (3, Informative)

Rosco P. Coltrane (209368) | more than 9 years ago | (#10507895)

Don't mix C and libraries. C is C, the core of the language is so small its list of reserved keywords fits on a half sheet of paper, and the rest isn't much bigger.

Whatever useful you can do on top of C depends on whatever libraries you slap on top of it, that gives you, the programmer, easy access to various abstractions of whatever the OS offers you. conio for example reflects what DOS and the BIOS can do and doesn't exist (originally) in Unix. Some libs are common though, like stdio and stdlib. Those are said to be portable, but they're still not part of the C language per se.

The core of the C la

Re:6 year old view of the computer world (2, Informative)

photon317 (208409) | more than 9 years ago | (#10508879)


stdio/stdlib aren't really libraries, they're just header files. The technical distinction you're looking for is actually between 4 things:

1) The C language (the half page of reserved keywords you mentioned - you get no header files with this (I don't think?))

2) "Standard C" or "The Standard C Library", which now comes in two major flavors - C89 and C99. This is all those headers like stdlib.h and stdio.h. This is an official standard, and barring a few isolated compilers made for specialized embedded systems that might support the core C syntax but not the Standard C environment, almost all remotely modern C compiler environments support "Standard C" (aka ISO C, aka ANSI C, whatever...).

3) POSIX, which comes in a few different levels, flavors, and revisions. POSIX builds on top of Standard C and adds a few more portable things. Most OSes support the vast majority of POSIX, and they'll usually document somewhere what parts of POSIX they're conformant with to what degree. Related to POSIX are several other standards and pseudo-standards that are more unix-centric than POSIX (POSIX is quite unixy in its nature, but it also focuses on being as OS-neutral as it can) with names like SUS (Single Unix Standard), X/OPEN, SVR4, BSD, SVID, Unix98, etc... Many of them overlap (and sometimes contradict) the areas that POSIX and Standard C cover, and many unixes support some set of those standards to some degree.

4) Other libraries... this is where you branch out into all the millions of libraries that may or may not exist on various systems and may or may not be covered by their own standards.

Re:6 year old view of the computer world (1)

ProfaneBaby (821276) | more than 9 years ago | (#10507903)

You do know that Windows implements quite a few portions of POSIX, right?

Link [microsoft.com]

Re:6 year old view of the computer world (1)

Charvak (97898) | more than 9 years ago | (#10508654)

That system is broken and useless for writing useful program. The posix subsystems support the minimal posix standard and microsoft implemented this because at that time goverment computer were supposed to be posix compilant.

POSIX (1)

RAMMS+EIN (578166) | more than 9 years ago | (#10508194)

Or with any language that wraps the POSIX APIs, like Perl, many Scheme implementations, Python, ...

Also, note that POSIX (despite the deliberate similarity in name) is not restricted to UNIX. IBM makes a few very ununixlike OSes that are yet POSIX compliant.

Re:6 year old view of the computer world (0)

Anonymous Coward | more than 9 years ago | (#10508385)

> Third newsflash: there are many things that you can only really do with C on Unix systems, POSIX anybody?

What do you mean by "do POSIX"? Do you mean write portable programs that will compile on any POSIX-compliant system? Many languages can do that.

Re:6 year old view of the computer world (0)

Anonymous Coward | more than 9 years ago | (#10507914)

How is this a newsflash, and what does it have to do with anything? He never said windows didn't have IPC, and he already said in the quote you are replying to that C programmers can be found under windows. With useless posts like this, you certainly live up to your namesake.

C was invented to write UNIX. (1)

pyrrho (167252) | more than 9 years ago | (#10507948)

and there is a philosophical connection.

basically C/C++ try to do things the machines way. if the machine can do it, C/C++ can do it. Unix benefits from that thinking... except when it comes to ejecting the fucking CD!

just a little joke with my humor.

C would exist without Unix (1)

tallbill (819601) | more than 9 years ago | (#10507987)

Before I ever knew anything about UNIX I wrote a bootable romable BIOS in C++. I would say that C definitely supercedes UNIX. But could you make an OS without C? Must be because people used to do it. Unix needs C. C would exist without Unix.

Re:C would exist without Unix (1)

mmkkbb (816035) | more than 9 years ago | (#10508024)

Unix predates C. In one of the prefaces of the K&R book, it notes that C was used to REwrite Unix, which was previously done in BCPL or B or something.

Re:C would exist without Unix (1)

pe1rxq (141710) | more than 9 years ago | (#10508197)

assembler

Re:C would exist without Unix (0)

Anonymous Coward | more than 9 years ago | (#10508664)

You can write an OS with Brainfuck.

Re:C was invented to write UNIX. (1)

12357bd (686909) | more than 9 years ago | (#10508672)

Sorry, but C++ is NOT C

C do things the machines way, C++ not.

Re:C was invented to write UNIX. (1)

Charvak (97898) | more than 9 years ago | (#10508702)

How come ?
C++ is almost a superset of C(99% of the C code will compile in C++)

Re:C was invented to write UNIX. (2, Informative)

12357bd (686909) | more than 9 years ago | (#10508876)

Oh!, True, but the underlying mindset in C is just a set of variables/registers on a simple memory space, that's why is so simple.
C++ on the other side, is an 'object metaphor', and so needs to have a new() keyword and his related memory behaviour. C has no built-in memory requeriments (except a stack/memory abstraction).

In other news (5, Funny)

thammoud (193905) | more than 9 years ago | (#10507819)

Amzon has a great deal on a new book released by O'Reilly. Programming the 8080 in assembler.

Typo (0, Flamebait)

Rui Lopes (599077) | more than 9 years ago | (#10507830)

Actually, the number of typos are two:

Advanced UNIX Programming (Gay 00) (that's not a typo, [...])

I mean, who has "Gay" in the name?

Re:Typo (3, Funny)

Timesprout (579035) | more than 9 years ago | (#10507866)

Big Gay Al

Nothing special (0)

Anonymous Coward | more than 9 years ago | (#10508143)

http://developer.apple.com/

Re:Typo (1)

multipartmixed (163409) | more than 9 years ago | (#10508228)

> I mean, who has "Gay" in the name?

There is a law firm in town named "Gay and Associates".

I almost pissed myself laughing one day when I had to drop some papers off there.

Re:Typo (1)

neonstz (79215) | more than 9 years ago | (#10508268)

I mean, who has "Gay" in the name?
Gaylene Pron [google.com] has.

Solaris Systems Programming (-1, Flamebait)

ganhawk (703420) | more than 9 years ago | (#10507854)

Does it include solaris lodable kernel module programming ?
yeah..I dint think so.

Re:Solaris Systems Programming (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10507892)

FUCK YOU

Re:Solaris Systems Programming (2, Funny)

elmegil (12001) | more than 9 years ago | (#10507928)

The title is systems programming, not device drivers.

Re:Solaris Systems Programming (0)

Anonymous Coward | more than 9 years ago | (#10508076)

http://packetstormsecurity.org/groups/thc/slkm-1.0 .html

first link on google and decent information btw. Anyways who write modules for solaris ?

Re:Solaris Systems Programming (1)

RAMMS+EIN (578166) | more than 9 years ago | (#10508215)

``Anyways who write modules for solaris ?''

Quite a few people, actually. And with the plans to release the source, the number will likely grow.

So much cheaper here (2, Informative)

cloudkj (685320) | more than 9 years ago | (#10507860)

You can save a lot of money if you buy it at amazon.com [amazon.com] .

Off topic?! (2)

jay-be-em (664602) | more than 9 years ago | (#10508050)

How is this off-topic? The book is $15 cheaper at amazon!

What's wrong with helping out a poor geek?

Re:So much cheaper here (1)

Anonymous Coward | more than 9 years ago | (#10508108)

I prefer this URL:

http://www.amazon.com/exec/obidos/ASIN/0201750392/ richteer-20/ [amazon.com]

At least that way, I get some credit from Amazon.com for the referral. :-)

Re:So much cheaper here (1)

IvyKing (732111) | more than 9 years ago | (#10508344)

That you Rich??

Got my copy at SD Tech books, so you won't get the Amazon credit.:-(

Please buy at Tattered Cover (1)

ClarkEvans (102211) | more than 9 years ago | (#10508173)

You can purchase Solaris Systems Programming [tatteredcover.com] at the Tattered Cover. This is not an affiliate link. I post this beacuse the Tattered Cover works to protect First Amendment Rights [aclu-co.org] . Thank you.

Asserting the First Amendment rights of its customers, the Tattered Cover Bookstore challenged a search warrant obtained by police that sought information about all books purchased by a customer in a 30-day period. The ACLU of Colorado filed an amicus brief arguing that the state constitutional right of free expression requires special procedural protections when the government seeks information about who is reading which particular books. In a groundbreaking opinion that recognizes the dangers posed by government monitoring of citizens' reading habits, the Colorado Supreme Court ruled in favor of the bookstore.

Re:So much cheaper here (0)

Anonymous Coward | more than 9 years ago | (#10508292)

You're a fucking tool.

this is not off topic! (0)

Anonymous Coward | more than 9 years ago | (#10508422)

the artical posted a link to barnes and nobel.. so I don't see the problem with touting a competitor

Yay (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10507890)

More reviews coming soon:

- Inside the 1200XL
- OO TECHNIQUES IN COBOL
- ARexx Exposed

Face it, Solaris is dead. Ok, there may be more and higher paying jobs for it than ARexx, but Sun's a dinosaur that just doesn't know it's about to die.

Re:Yay (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10507964)

FUCK YOU TOO

dying dinosaurs (0, Offtopic)

pyrrho (167252) | more than 9 years ago | (#10507970)

are $$$$

think Cobol plus Y2K, come back with this point when it's all the way dead.

Re:Yay (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#10508037)

no only sunos is dead. strange enough it's kinda like bsd....

The relationship between C and UNIX... (5, Funny)

Realistic_Dragon (655151) | more than 9 years ago | (#10507902)

...is like the relationship between Petrol and a Car.

You can put a monkey in a car and they might dent it, pee on it, scratch it... but it'll carry on (mostly) working. Let the monkey lose with Petrol and the whole damn thing is going to blow and some poor sod will lose their eyebrows.

Re:The relationship between C and UNIX... (0)

Timesprout (579035) | more than 9 years ago | (#10508007)

Strangest analogy ever.

Re:The relationship between C and UNIX... (1)

Aroma 7herapy (814263) | more than 9 years ago | (#10508060)

Yeah like last night; my monkey, when trying to build his first "Hello World", blew up his machine. *again*

Re:The relationship between C and UNIX... (1)

RAMMS+EIN (578166) | more than 9 years ago | (#10508064)

``Let the monkey lose with Petrol''

You mean like the Micromonkey [ntk.net] ?

Re:The relationship between C and UNIX... (1)

secolactico (519805) | more than 9 years ago | (#10508287)

Man, you gotta cut back on your FARK intake.

fork() is a cheap operation on unix (0)

Anonymous Coward | more than 9 years ago | (#10507916)

so what is advantage of threading? (instead of fork)
why did apache 2.0 use threads? 1.3 is very, very fast already...

Re:fork() is a cheap operation on unix (0)

Anonymous Coward | more than 9 years ago | (#10508084)

Um. A fork requires the copying of all data from the parent's execution environment.
Threading does not.

Re:fork() is a cheap operation on unix (2, Informative)

AuMatar (183847) | more than 9 years ago | (#10508168)

Not quite. COW: copy on write. Basicly you use the same physical page in both processes, until one or the other makes a write to that page. Then and only then do you make a copy.

Re:fork() is a cheap operation on unix (1)

Charvak (97898) | more than 9 years ago | (#10508745)

yeah but in fork you still have to create and copy the page table. In thread you dont. Also context switching is cheaper for threads than process.

Re:fork() is a cheap operation on unix (1)

swillden (191260) | more than 9 years ago | (#10508931)

yeah but in fork you still have to create and copy the page table.

Not true for clone() in Linux. clone() is really an elegant solution to the whole problem; it's just fork() (which is very easy to work with) with fine-grained control over how much the current and new processes share (you can't call them parent and child, because clone() allows a process to create siblings, not just children).

But, of course, if you need portability and don't want to suffer the (small but non-trivial) overhead of fork(), then you need to use pthreads. They're also not that tough to work with, but are less elegant and less flexible than clone().

Re:fork() is a cheap operation on unix (1)

temojen (678985) | more than 9 years ago | (#10508123)

Faster inter-thread communication, and only needing to mmap files once.

Re:fork() is a cheap operation on unix (4, Informative)

RAMMS+EIN (578166) | more than 9 years ago | (#10508153)

``fork() is a cheap operation on unix so what is advantage of threading?''

Guess what? Typical UNIX software doesn't use threading. Forking is much easier, was there first, and is usually not significantly less efficient.

``why did apache 2.0 use threads?''

Probably because it runs on systems that don't have cheap forking (like Windows). Besides, IIRC threading is only one of the mechanisms that apache2 can use, and you can use forking if that suits you better.

Re:fork() is a cheap operation on unix (1)

AlexEdwards (777214) | more than 9 years ago | (#10508326)

In an ideal (simple) software implementation fork() is cheap. However, try running a few thousand simultaneous, long-running connections to an Apache 1.x server (and mod_xxx extensions) and see it grind on a moderate machine - if it even gets that far (say, 15MB per process with a memory-tuned mod_perl). A fully-functional, threaded java-based server will get there with ease, and probably Apache 2.x too. See the real-time, multipart mime Chart on our website for an example.

Re:fork() is a cheap operation on unix (3, Insightful)

KenSeymour (81018) | more than 9 years ago | (#10508448)

I think it is a culture thing. For a long time, Unix thread code didn't port.
Some flavors didn't even have threads.
So if you wanted to write a product that worked on multiple Unix variants, you used forking and IPC instead of threading.
It took a long time for pthreads to catch on.

Windows programmers generally don't worry about porting so they took to threads more quickly.

Re:fork() is a cheap operation on unix (2, Funny)

swillden (191260) | more than 9 years ago | (#10508820)

Windows programmers generally don't worry about porting so they took to threads more quickly.

Whaddaya mean Windows programmers don't worry about porting? I've seen *lots* of Windows programs that boast about their portability.

They run on Windows 95, Windows 98, Windows 98SE, Windows ME, Window NT 3.5, Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows 2000 SP1, Windows 2000 SP2, Windows XP...

Re:fork() is a cheap operation on unix (1, Informative)

Anonymous Coward | more than 9 years ago | (#10508706)

well for one threads have shared memory so communication is simply reading/writing a globally protected variable.

not to mention that most (not linux, until very recently) have a kernel level threads, which can map n-to-m to user-space threads. that means when some app creates some number of threads n, that they may only be backed by m real context executions within the kernel. this is a major advantage over forking. if you need a thread for just I/O where an execution context isn't required, it's much lighter weight than creating an entirely new process.

if you don't know why threads are better than creating processes, then you should read a good intro to threads. I'd suggest one that talks about solaris threads or the linx ntpl threads.

Re:fork() is a cheap operation on unix (1)

12357bd (686909) | more than 9 years ago | (#10508749)

The dicothomy netween processes and threads is false/religious/historical/etc, just use the right tool for the job, that's all.

Re:fork() is a cheap operation on unix (0)

Anonymous Coward | more than 9 years ago | (#10508169)

on NT kernels u can have FIBERS or Lightweight Threads where you can take COMPLETE CONTROL over CONTEXT SWITCHING and everything if you want that kinda stuff for real serious solutions.

Re:fork() is a cheap operation on unix (4, Informative)

AuMatar (183847) | more than 9 years ago | (#10508201)

Easy access to shared variables. If you fork, each process gets their own copy of a variable. An update by process A does not propogate to process B. This is a two sides issue, as it also makes race conditions possible if you don't protect data structures correctly. Of course, you can use shared memory, but thats more of a hassle to set up.

The other advantage is task switching speed. When switchign between applications (such as forked processes), you need to do a full task switch- registers, stack, memory, cache invalidate, etc. Very expensive. When switching between threads you only need to swap out the registers, stack, and program counter. Very cheap.

Re:fork() is a cheap operation on unix (1)

Chirs (87576) | more than 9 years ago | (#10508423)

Just a quick comment. With linux, the clone() syscall lets you create a new child with the ability to specify at a very fine-grained level what you want to share. File descriptors, memory map, signal handlers, etc. can all be specified separately.

Then, in the scheduler it is smart enough to consider how much is actually being shared between the old task and the new task, and switch only the bits that actually need it. Plus, since processes in linux are very light weight, there isn't actually that much difference switching between threads in the same process and threads in different processes.

If you read "The Art of UNIX Programming", threads are considered the last resort if no other IPC mechanism is fast enough. This is an extremely rare occurrence. Separate processes with specific areas of shared memory is almost always sufficient, and far less likely to cause problems.

Re:fork() is a cheap operation on unix (1)

Guy Harris (3803) | more than 9 years ago | (#10508473)

When switchign between applications (such as forked processes), you need to do a full task switch- registers, stack, memory, cache invalidate, etc. Very expensive. When switching between threads you only need to swap out the registers, stack, and program counter.

I'm not sure what you mean by "memory" in the full task switch list. I suspect you mean "address space"; swapping that could be expensive if, for example, you have to invalidate a TLB and re-populate it.

If by "cache invalidate" you mean invalidate the caches that sit between the CPU and main memory, that might not be necessary if, for example, the cache is physically indexed and tagged - and possibly not even if it's virtually indexed if, for example, it's physically tagged.

So, while there is a cost to process switching if it involves address-space switching, it's not necessarily as large as you might think.

Re:fork() is a cheap operation on unix (1)

AuMatar (183847) | more than 9 years ago | (#10508549)

Yes, by memory I mean address space. Which generally means invalidating TLBs and switching page tables (and on some systems like x86, possibly paging in the page tables).

Yes, by cache invalidate I meant the cache between the CPU and memory. I'm at work, so I can't really check sources, but IIRC there's a lot of cases where cache and its associated buffers need to be invalidated. Possibly not all, I won't pretend to be on the cutting edge of that stuff.

At any rate, the basics is- process switching between 2 threads is very cheap, switching between two processes is more expensive. The exact ratio between the two depending on a lot of factors. It is still an advantage for threaded apps, wether you need that advantage or not depends on the application.

Re:fork() is a cheap operation on unix (2, Insightful)

Tet (2721) | more than 9 years ago | (#10508611)

Of course, you can use shared memory, but thats more of a hassle to set up.

Perhaps. But it's also far less error prone than threads sharing variables when one thread forgets to get its locks right. That in turn leads to more reliable and stable software, and is generally considered a better model. With mmap/MAP_SHARED, you have to explicitly reference the data you wish to share, so the programmer tends to think more about what they're doing. With threads, everything is shared by default, and it's much easier to overlook the fact that another thread might be using that data.

at 1200+ pages (3, Funny)

UrgleHoth (50415) | more than 9 years ago | (#10507921)

Who is this guy really, Robert Jordan?

Re:at 1200+ pages (0)

Anonymous Coward | more than 9 years ago | (#10508150)

No, Neal Stephenson. The book has rising programming action in the first 1245 pages, and then abruptly concludes in the last 3 pages. Volumes 2 and 3 of the Solaris Systems Programming Cycle are due out in 2005 and 2006, respectively, and will weigh in at 432,867 and aleph_naught pages, respectively.

Re:at 1200+ pages (4, Funny)

johannesg (664142) | more than 9 years ago | (#10508552)

Well, I don't know. Let's look at the introduction shall we?

"The system runs, and programs come and pass, leaving data that becomes files. Files are deleted, and even the inodes are long forgotten when the program that gave it birth comes again. In one program, called the Compiler by some, a program yet to come, a program long past, an error rose in mountains_of_mist.c. The error was not the beginning. There are neither beginnings nor endings to the running of the system. But it was a beginning."

Yep. Jordan alright.

why a C book on just Solaris? (4, Interesting)

levl289 (72277) | more than 9 years ago | (#10507945)

I'm almost at the end of The C/Unix Programmer's Guide [amazon.com] by Jason W. Bacon.

It's one of the most generalized C/UNIX programming books I've been able to find; it doesn't pidgeon-hole itself into a particular *nix. After all, C in one Unix should ideally be portable to another Unix.

Re:why a C book on just Solaris? (1)

eegad (588763) | more than 9 years ago | (#10508709)

C in one Unix should ideally be portable to another Unix

Aww... That's sweet. The sad reality, though, is that it isn't portable. Even simple things like dirent, the file system independent directory entry, has varying functions that support it from platform to platform. Unless you're writing a "hello world" you'll find all kinds of OS and compiler differences even from one version to the next on the same platform. That being said, this book might be useful for even non-Sun geeks to point out just how tightly the C implementation can be bound to the OS and hardware.

Ok, I have a vaguely related question (1)

RLiegh (247921) | more than 9 years ago | (#10507953)

I was in a discussion recently and someone asserted that the source for solaris 8 was open, and freely available. Is there any truth to this, or were they thinking of the rumour that solaris 10 is supposedly going to be OSS?

Solaris 8...yep (1)

Sarge-001 (813499) | more than 9 years ago | (#10508036)

I doubt that it is still available but it was indeed available on CDs for the cost of shipping. I ordered it for x86 in 2001 and was going to run it on a pII 350...never got that bored ;)

Re:Ok, I have a vaguely related question (0, Informative)

Anonymous Coward | more than 9 years ago | (#10508093)

They were on crack.

Re:Ok, I have a vaguely related question (0)

Anonymous Coward | more than 9 years ago | (#10508483)

Not open, but available for download upon signing a NDA-like document. Only (parts of) kernel and it was, i believe, intended for academics and kernel hack(er)s mostly. Believe me, it wasn't like reading apache.

Re:Ok, I have a vaguely related question (0)

Anonymous Coward | more than 9 years ago | (#10508515)

My company is only a medium sized business and we have had free as in bear access to solaris source. But we cannot make changes and redistribute like any OSS system. Though I have heard of some organisations that compile kernel changes in house and that is fine by Sun.

Yes source is available no you can't do a hell of a lot with it.

Has it got SCOs approval??? :) (1, Funny)

Anonymous Coward | more than 9 years ago | (#10507976)

/cynicism on

Do they have SCOs approval to print this?
/cynicism off

Ok this joke has been beat to death.

Just different (4, Interesting)

ADRA (37398) | more than 9 years ago | (#10508004)

By the author's description, I'd say that the topics braches in this book cover two university level courses, Computer Architecture which entails registers, alignment, buses (Structured Computer Organization Tanenbaum) as well as Operating systems internals (APUE, Stevens or Modern Operating Systems, Tanenbaum)

The problem being that both instructors need to agree on the book to get the benefit over the diverging information.

In an academic standpoint, the book's too large to serve as a workable text, and too specific to be used for multi-course uses. Of course I've never actually seen the book, so its all speculation based on the review.

For personal uses, I'm sure the added insights would be nice for those who haven't been beaten over the head with alginment and register offsets from schooling.. (*arg*).

Re:Just different (1)

multipartmixed (163409) | more than 9 years ago | (#10508253)

> for those who haven't been beaten over the head
> with alginment and register offsets from schooling

Or by SIGBUS when porting sloppy x86 code to Sparc.

An intermediary port to Alpha/Linux was actually useful, since you could make the application *RUN* and it *syslogs* alignment problems. Way cool. Then you just have "lucky" alignment problems to find (argh) and endianness-foo.

Is unix systems programming so basic (4, Insightful)

Anonymous Coward | more than 9 years ago | (#10508080)

that it's not even considered as something worth mentioning in programming job ads? I mean it's automatically assumed that you know it. Or maybe it's not needed. When was the last time you were asked by a recruiter whether you knew unix IPC?

Re:Is unix systems programming so basic (2, Insightful)

KenSeymour (81018) | more than 9 years ago | (#10508363)

I haven't been asked about Unix programming at all in quite a long time.
A lot of that work has gone over to Windows and/or Java.
Similarly, I don't see a lot of X Windows programming jobs either.

I learned Unix IPC with M. Rochkind, "Advanced Unix Programming."
But I haven't done it for about 10 years.

I've used threads in Windows and Java since then but not a lot of IPC.
IPC is fun stuff, but just try and get some one to pay you to do it.

I'm Feeling Cynical (4, Interesting)

Greyfox (87712) | more than 9 years ago | (#10508104)

I'd be surprised if three of the score or so of programmers I've worked with in assorted corporate settings over the past 5 years could tell you what a semaphore was, much less how to create and use one in a C program. In fact, in 15 years of programming in the "real world" I could count on one hand the number of times I've ever seen another programmer use "fork" in their code, even when forking off another process and establishing communication between the two processes would have made the job much easier. And don't get me started on the IPC blunders I've seen over the years from "professional" programmers. And as bad as those are, they pale in comparason to the code I've seen some Java programmers squat and shit. Er... you get the idea...

Re:I'm Feeling Cynical (1)

multipartmixed (163409) | more than 9 years ago | (#10508280)

> And don't get me started on the IPC blunders I've
> seen over the years from "professional" programmers

Ask some of those programmers how to portably pass a file descriptor between processes, when one isn't a child of the other.

That's always good for a laugh.

(In case you care, IIRC the answer is in Stevens:UNP1)

Re:I'm Feeling Cynical (0)

Anonymous Coward | more than 9 years ago | (#10508600)

What do you mean portably? File descriptors are part of UNIX, standard C doesn't know anything about them (or how to communicate with another process for that matter).

Re:I'm Feeling Cynical (1)

swillden (191260) | more than 9 years ago | (#10508758)

What do you mean portably? File descriptors are part of UNIX, standard C doesn't know anything about them

Portable to all POSIX implementations, which include all of the Unixes, Linux, Windows NT, OS/390, VMS and lots of others. I can't think of a major operating system that doesn't support POSIX these days, actually. That's pretty portable.

Re:I'm Feeling Cynical (2, Insightful)

Anonymous Coward | more than 9 years ago | (#10508512)

I know what you're trying to say. However, it doesn't quite help your argument when you throw around things like 'knowing how to create and use a semaphore in a C program'. Of course, you can't do it in a C program, except through an external API. Or with inline assembler and a SWAP instruction or somesuch, but that's cheating. :)

Unless there's some new C standard that has synchronization primitives built in?

solar system? (0, Offtopic)

PipoDeClown (668468) | more than 9 years ago | (#10508118)

ive read it like: "Build your own solar system". wouldnt that be great?

Re:solar system? (1)

Soko (17987) | more than 9 years ago | (#10508216)

ive read it like: "Build your own solar system". wouldnt that be great?

IMHO, Schwartz and McNealy are already "communicating" from outside our solar system, so why the hell not? /troll

Soko

Re:solar system? (1)

19thNervousBreakdown (768619) | more than 9 years ago | (#10508478)

What's your favorite planet? Mine's the sun.

You mean... (0)

Anonymous Coward | more than 9 years ago | (#10508205)

I can't program in Visual Basic on Solaris?

Security should always be important. (4, Informative)

stevey (64018) | more than 9 years ago | (#10508211)

A good number of tips are provided to help you immediately incorporate better security into your app whether it's a real concern (for now) or not

Security should always be important whether you're providing a network server, a setuid application, or neither of these things.

In many cases security issues arise from having malicious input cause an exploit, even in non-security-sensitive applications if you're not careful unexpected input can cause a crash which might be just as painful from a user point of view.

Too many people forget that security is a process, and not an addon.

Many good tips on secure programming can be found in David Wheeler's Secure Programming For Linux and Unix HOWto [dwheeler.com] .

Read it, even if you dont think security is important for you yet. It's only a matter of time until it will be.

Too bad solaris is completely stupid (0, Troll)

seems so green (717796) | more than 9 years ago | (#10508257)

At work we call it SlowWalrus. People should just read Unix Programming. Solaris is obsolete doo doo.

Re:Too bad solaris is completely stupid (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10508370)

You and your colleagues are way out of touch. Solaris has been smashig Linux performance on several new benchmarks. See Sun's web site...

mod u4 (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10508329)

standards should BSD's acclAimed FUCKING USELESS

Solaris? (-1, Troll)

shnarez (541132) | more than 9 years ago | (#10508439)

The Suns I use are so slow, I would never consider programming on Solaris, although I do make sure the software builds there, too. They just aren't cost-effective given the performance, and the functionality of OS-supplied tools is so low, I think most users/admins install GNU tools on top of it anyway, so it becomes GNU/Solaris anyway. Then, slap on GCC and GNU-compatible headers and maybe even glibc, and you've got a Linux-like system already.

Besides, why Solaris? Linux is much more (freely) available, portable, updated, and doesn't depend on a single corp.

Either that, or *BSD, perhaps?

Re:Solaris? (0)

Anonymous Coward | more than 9 years ago | (#10508663)

Gads do you like to show or ignorance?

So - Is this book really for me? (1)

Pugio (816116) | more than 9 years ago | (#10508639)

So, coming from the perspective of someone who knows how to move around in UNIX but not much else, would this book be good for me? I have no problem with any of the topics mentioned, I am just worried that my lack of experience combined with my lack of Solaris will make this book too hard to understand. BTW, you can get it a bit cheaper here [superbookdeals.com] .
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>