 |
| Linux Magazine / DEPARTMENTS / |
One of the nice things about being a programmer is that you get to work in a simplified world. Computers are designed and built to do exactly what you tell them to do (even if it's not what you mean), and to do the same thing over and over again, yielding nice, reproducible results. The reason programs are so well behaved is that they normally execute sequentially. One step follows another, and nothing happens in between, so your data will stay the same as it was when you last touched it. Your program's flow becomes obvious and any bugs that you may have are reproducible.
In the last column, I talked about how to read and write from multiple file descriptors seemingly simultaneously with the select() function call. Using multiplexed I/O lets programs block while waiting for notification that some file descriptors are ready for reading or writing.
Linux programs often need to access more than one file at the same time. This can require a bit of coordination -- or multiplexing -- of the I/O. Under normal circumstances, the order in which different files get accessed by a program is determined by a simple algorithm. For example, the cat command employs the following algorithm to achieve this:
In previous columns, we've looked at the Linux file model, and discussed many of the Linux system calls. This month, we're going to talk a bit more about the semantics of the read() and write() system calls. Remember that read() and write() have very similar prototypes:
Last month, I wrote about Linux's file access API. For this month's column, I'm gong to talk about some of the other important file-related system calls, and touch on how the kernel file implementation affects the system call interface.
While developing the GIMP (GNU Image Manipulation Program) a few years back, Spencer Kimball and Peter Mattis decided that it might be fun to write a user interface toolkit to go along with it. And so they created GTK+ (the GIMP Toolkit) -- a library of "widgets" that makes it easier for developers to build GUI-based application. A widget is one of the various components of a graphical application; a toolbar, for example. The widgets provide programmers with pre-built dialog boxes, windows, menu bars and other GUI components. Having a pre-built foundation for these user interface components greatly speeds development of GUI applications and also enables applications built with those widgets to share a common "look and feel".
One of the most important abstractions of the POSIX API is the file. While nearly all operating systems provide files for permanent storage, all versions of UNIX provide access to most system resources through the file abstraction.
Before anyone can write software for a particular operating system, they must first understand the programming interfaces the system provides. Many of Linux's APIs are defined by the POSIX standard; other APIs which Linux provides were originally introduced by groups like the X Consortium or by other operating systems. At the core of all of these APIs is Linux's system call interface, which every other system API is built around.