Slashdot Log In
Solaris Systems Programming
from the solaris-system-alignment dept.
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.
Dougla Adams (Score:5, Funny)
In other news (Score:5, Funny)
So much cheaper here (Score:2, Informative)
Please buy at Tattered Cover (Score:2)
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 express
The relationship between C and UNIX... (Score:5, Funny)
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... (Score:2)
You mean like the Micromonkey [ntk.net]?
Re:The relationship between C and UNIX... (Score:2)
at 1200+ pages (Score:4, Funny)
Re:at 1200+ pages (Score:5, Funny)
"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.
Parent
why a C book on just Solaris? (Score:5, Interesting)
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.
Just different (Score:5, Interesting)
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 (Score:2)
> 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 (Score:4, Insightful)
Re:Is unix systems programming so basic (Score:3, Insightful)
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 (Score:5, Interesting)
Re:I'm Feeling Cynical (Score:2)
> 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 (Score:2)
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 (Score:2, Insightful)
Unless there's some new C standard that has synchronization primitives built in?
Security should always be important. (Score:4, Informative)
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.
great book review (Score:2, Interesting)
Re:6 year old view of the computer world (Score:4, Informative)
Parent
Re:6 year old view of the computer world (Score:4, Insightful)
Parent
Re:6 year old view of the computer world (Score:4, Informative)
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
Parent
Re:6 year old view of the computer world (Score:3, Informative)
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
POSIX (Score:2)
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 (Score:3, Informative)
Re:C was invented to write UNIX. (Score:2)
Sorry, but C++ is NOT C
C do things the machines way, C++ not.
Re:C was invented to write UNIX. (Score:3, Informative)
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).
Re:C would exist without Unix (Score:2)
Re:Typo (Score:4, Funny)
Parent
Re:Typo (Score:2)
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 (Score:2)
Re:Solaris Systems Programming (Score:3, Funny)
Re:fork() is a cheap operation on unix (Score:2)
Re:fork() is a cheap operation on unix (Score:5, Informative)
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.
Parent
Re:fork() is a cheap operation on unix (Score:4, Insightful)
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.
Parent
Re:fork() is a cheap operation on unix (Score:3, Funny)
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 (Score:2)
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 (Score:4, Insightful)
It depends what you call "typical".
A web server generally doesn't need shared data. Apache 1.x only uses shared data for a small amount of statistics gathering/monitoring, which is a very small amount of work compared with the job of actually serving HTTP, so the minor overhead in managing the shared data doesn't hurt very muvh at all.
The same applies to other kinds of server where little or no synchronisation is needed (e.g. telnet server, ftp server, ssh server).
At the other end of the spectrum is a program which does need synchronisation, but each request/response is quick. An X server is a good example. In this case, a single-task tight event loop architecture is appropriate.
And in the middle, you have a lot of jobs which aren't so simple. A typical DBMS is a good example of this. You have multiple concurrent tasks, which may take an unbounded amount of time, and which may require a nontrivial amount of synchronisation. The jobs aren't effectively sequential, meaning that SMP scalability is possible, but they're not completely isolated either. This is the kind of task where multi-threading is almost always the right answer.
Multi-threading is also commonly found in interactive GUI applications, where there may be long background tasks in conjunction with low-latency requirements.
So while it's true to say that typical Unix software, in the sense of most software that comes packaged on the CD from your vendor, is not multi-threaded, that's because most of that software doesn't have difficult synchronisation or scalability problems to solve. On the other hand, a lot of the software that you might buy or obtain after that is indeed multi-threaded.
Parent
Re:fork() is a cheap operation on unix (Score:5, Informative)
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.
Parent
Re:fork() is a cheap operation on unix (Score:2)
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 d
Re:fork() is a cheap operation on unix (Score:2)
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 invalidat
Re:fork() is a cheap operation on unix (Score:2)
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 betw
Re:fork() is a cheap operation on unix (Score:3, Insightful)
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 eas
Re:fork() is a cheap operation on unix (Score:3, Informative)
Re:fork() is a cheap operation on unix (Score:2)
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(
Re:fork() is a cheap operation on unix (Score:3, Informative)
Is clone() the clone of vfork in linux ? (Pun intended)
:-)
Actually vfork(), as defined by POSIX at least, doesn't create a child with a shared memory space, exactly. Well, maybe it does, but you're not supposed to use the memory. In a POSIX program you're not supposed to modify any memory in a vforked child (behavior is undefined if you do). The only purpose of vfork() is to avoid wasting time copying all of the page tables immediately before calling exec(), which will replace the whole current proc
Re:solar system? (Score:2)
IMHO, Schwartz and McNealy are already "communicating" from outside our solar system, so why the hell not?
Soko
Re:Ok, I have a vaguely related question (Score:3, Informative)
Open Source Solaris (Score:3, Informative)
Keep your eyes out, Solaris is being open sourced. The pilot has been underway now for a few weeks. I'm sure that there will be a big announcement and press release when it happens, and you can bet that Jonathon [sun.com] will certainly mention it.
Before the license flames start, there is a commitment that the license will be OSI compliant. There would be little point to the exercise otherwise.
Tp.