Issue 1-31, July 10, 1996

Be Engineering Insights: DR8 Sneak Preview: Semaphore & Port Changes

By Dominic Giampaolo

One of the first things most developers do when given a new operating system is to peruse the APIs to get a feel for what's there, what isn't, and what should be. Most of our developers have done exactly that and voiced their opinions on a number of issues. In looking at the Be OS kernel API, the first thing that strikes any classic OS weenie is the lack of nonblocking versions of read/write_port() and acquire_sem(). We've been chastised for this, so we implemented additional functions for DR8 that offer solutions to these problems. Let's start at the bottom: Semaphores. In reviewing the semaphore API we noticed that the function names were getting a little out of hand. For example, there were four versions of the semaphore-acquisition function:

acquire_sem_count(sem, count)
acquire_sem_timeout(sem, timeout)
acquire_sem_count_timeout(sem, count, timeout)

The kernel had several more versions of these functions with even longer names. Clearly this was not an API that could grow. For DR8 there are now only two semaphore routines:

acquire_sem_etc(sem, count, flags, timeout)

The new routine, acquire_sem_etc(), allows for a bit more flexibility in specifying how you want to acquire a semaphore. The 'sem' and 'count' arguments are of course the same as before. The new 'flags' argument lets you set certain attributes when acquiring the semaphore; in particular, you can set the semaphore's "apply timeout" flag, B_TIMEOUT. By applying the timeout and passing a timeout value of 0, you tell the acquisition function that you don't want to block. (In DR7, a timeout of 0 meant "wait forever").

Given the presence of a nonblocking semaphore, it becomes trivial to implement nonblocking read_port() and write_port() functions (in fact it took less than five minutes!). The implementation mirrors that of acquire_sem(); the following functions are new for DR8:

read_port_etc(port, code, buf, size, flags, timeout)
write_port_etc(port, code, buf, size, flags, timeout)
port_buffer_size_etc(port, flags, timeout)

The 'flags' and 'timeout' arguments to these routines follow the same conventions as the acquire_sem_etc() routine. So by combining the B_TIMEOUT flag with a timeout of zero you can do nonblocking port operations. Of course you can specify longer timeouts if you desire.

The use of small or zero timeouts does raise some issues though: One fear we have regarding the nonblocking functions is their potential for abuse. The functions make it easy to write a program that constantly polls a port or semaphore and simply burns CPU cycles while not accomplishing any useful work. Doing that is what some people refer to as "A Bad Thing"; something we'd like to avoid. And so let us state up front that using a zero or very small timeout to constantly poll a port or semaphore is not acceptable.

How do you use these routines in a well-behaved manner then? One example is our Browser, which has a thread that periodically does some work and needs to know when to exit so it can cleanly free data structures, and so on. A way to accomplish this is to have the thread do a nonblocking acquire of a semaphore before it does its work, and then release the semaphore when it's done. When the Browser wants the thread to exit it simply grabs the semaphore and does a wait_for_thread(). When the work thread attempts to acquire the semaphore in a nonblocking manner, it will get an error code (because the main Browser thread acquired the semaphore). When the work thread fails to acquire the semaphore it knows it's time to exit. This is a very simple mechanism that requires very little extra code in either thread while producing clean, consistent results.

As another example, consider a program where a background computation thread (rendering, FFTs, and so on) works on data while a front end allows a user to manipulate a GUI. Suppose that while the computation thread is running the user adjusts some parameter that affects the computation. Instead of waiting for the computation thread to finish before being able to inform it of the changes, the GUI thread can send the computation thread a message to tell it to restart. The computation thread can periodically poll for these messages by doing a nonblocking read of a message port. This is of course much cheaper and easier to do than creating and killing threads on the fly. It also falls outside our admonition about burning CPU cycles needlessly, because the computation is performing useful work.

Of course nonblocking port operations aren't the only use for the timeout parameter. The use of longer timeouts is very handy when you want to avoid hanging on a client or server that fails to respond within some specified time. By using timeouts you can improve the robustness of your applications and make them impervious to misbehaving clients or servers (also known as"A Good Thing").

These are just a few of the avenues you can explore with nonblocking and timeout-based semaphore and port operations. We hope that this functionality will allow you, our developers, to more easily create applications that wow, excite, and titillate the public (OK, maybe not titillate, but at least excite and wow).

Be Developer Talk: Technical Magic

By Gary JP Hewett

I've always been an entrepreneur, writing database and production automation software for large catalog and mail order companies. The technology in this field has a long way to go, but I'm excited about being a part of the process. There's a certain satisfaction in getting clients—who aren't necessarily technically literate—involved in the process of designing the tools that they'll be using. Even the smallest indoctrination can prevent the horror of the ill-informed client who asks for miracles and then merely shrugs when we deliver them.

There are four of us at Technical Magic. We've been spoiled for years working with NeXT software, but the integrated database on the BeBox was an ultimately compelling feature. More than anything else, we need a machine that has good database tools, reliable performance, and network scalability. I've only had my BeBox for about an hour so far, but things look exciting. It seems that there may be some nasty font issues, and Orb has crashed the machine a couple of times, but I'm impressed with the dual processors and graphics appear real snappy. I've got more than a few things yet to find in there I'm sure!

In the short term we hope to evaluate platform development tools, and then build baseline business software. (Time and Contact Managers, Financial Products, and so on—I figure all those prosperous Be developers would like to count their coins on a BeBox, right?) Recovery software might also be an area I'll explore. I'd also like to develop hardware that attaches to the GeekPort™—break-out boxes and other attachments.

This is, of course, a young machine that will create a new market. One of the exciting things about the BeBox is that because of its newness, I can influence the markets that are created. We'll see.

"Are You Crazy?"

By Jean-Louis Gassée

We've said it many times: Harness a new platform (ours) to the Internet, and you create a great opportunity for small, unenfranchised software developers. On older platforms, a few dominant players, mostly US-based, can use their muscle to prevent fledgling new entrants from reaching critical mass. And without the affordable promotion and electronic distribution made possible by the Internet, young companies are killed by the expense of marketing.

As a result of what I've said and left unsaid, several readers of this newsletter have questioned our apparent bias in favor of smaller software developers. Your messages were invariably tactful—but the subtext was clear:

"Are you crazy?"

"Aren't you better off courting the established players, getting them to port their most successful applications to the BeBox, rather than looking for the next John Warnock or the next Mitch Kapor amongst the Diaspora of unwashed geeks?"

You've got a point.

One could make a nice list of industry-trusted, media- or communications-intensive applications that would look great and run even better if ported to the BeBox. Name your domain, from image processing to video editing, from multimedia authoring to digital audio, web services and software development for other platforms... Each time, a handful of titles comes to mind. Isn't this the best way, the only way perhaps, to find the "tractor application" the BeBox must get, or die?

The argument is seductively simple and intuitively obvious. But a couple of observations play against it. The first observation comes from past history. If memory serves, no new platform took off as a result of a port from an older one. For instance, none of the DOS or Apple ][ applications that were ported to the Macintosh actually helped the Mac. On the other hand, the home-grown PageMaker did (and, later, also became successful on Windows).

The second observation, or factor, is short-term economics. The primary business of any large company that's already successful on Windows or the Mac is fighting the competition and supporting existing customers. The short-term return on an investment in a new platform with a small installed base doesn't look good on Wall Street.

Still, let's assume that there exists a Be champion inside one of the fast-moving, successful software companies. She or he convinces management of the long-term benefits of betting on the Be platform, gathers political support inside the organization, and gets the human and financial resources needed for the port. What's required to complete a product that works and sells?

In the end, working with a large, established player means working against the conservative forces generated by its very success while using its momentum to help our platform take off. By now (I hope) I'll have confused our esteemed readers enough to convince them that working with the leading software companies isn't "do or die"—it's not a slam dunk. For example, we'd be flattered to see a "straight" port of Photoshop work on the BeBox, but we'd rather convince Adobe to do on the BeBox what we did ourselves: Maximize the benefits of innovation by shedding the baggage from the past. We don't know yet if they or their colleagues will do it, or if a small company will, but we'll do our best to find out.

BeDevTalk Summary

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads. To subscribe to BeDevTalk, visit the mailing list page on our web site:


Subject: Suggestions for a Help system?

A/K/A: HTML Help Files

More HTML talk: It was suggested that a proposed "super-HTML" be used to encode entire interface layouts.


Subject: OpenDoc

A/K/A: Live update OLE? NO!
A/K/A: OLE, OpenDoc

The OpenDoc debate flared up when it was suggested that OLE might be a welcome addition to the Be OS. Many listeners wrote in to object, citing authorities and their own experiences. It was suggested that the cogent questions are not about the quality of OpenDoc, but

  1. should Be use OpenDoc simply because it's an available standard,

  2. is OpenDoc so widely accepted that it would be dumb not to support it, and

  3. if it's actually accepted now (or soon) how long will this acceptance last?


Subject: Memory usage

Some confusion over RAM, VM, the disk cache, and other memory matters: Does VM exist? Can it be configured? Why does the BeBox immediately eat up nearly all available RAM?

THE BE LINE: Yes, VM does exist and, no, it can't be "configured." The latter is a feature, not a bug. (You can lock data into RAM by using "areas"—see the Kernel Kit—but beyond that, the OS does the driving.) Furthermore, the VM system has been improved in DR8 for more efficient paging.

Regarding the "where'd all my RAM go?" business: The phrase "available RAM" (as used by Pulse, for example) is a misnomer in a VM system, particularly as it connotes evaporating resources. Rejoice when your machine is using nearly all its RAM; that's what it's there for.

Subject: BeBox slower to boot lately?

Why does rebooting a heavily file-laden BeBox take a disproportionate amount of time?

THE BE LINE: There are some boot-time database integrity checks that will be removed once we're sure the database is unimpeachably stable. This series of checks, whose duration is related to the number and size of the files on your disk, is the primary cause of the boot delay. The checks will probably remain in place until the file system rewrite (post DR8). We apologize for the inconvenience.

Subject: OS Suggestions

Be should provide a way to programmatically retrieve and set the colors that are used to draw GUI widgets (the encapsulation of such was termed a "pen"). When it was pointed out that a single widget is often a blend of many colors, the proposition became: The programmer should be able to declare a window's title bar to be blue (for example), and the system should provide all the appropriate shading within the bar.

On other subjects, developers are yearning for UI guidelines and for the scoop on "App Modeler," the GUI-building tool.

THE BE LINE: The UI guidelines and App Modeler will be part of DR8.

Subject: View/ListView and font info

An initial query about how to retrieve font info turned into a discussion of whether it would be more intuitive/easier/elegant to express coordinates as a device-independent measure (as compared to the status quo where points == pixels).

THE BE LINE: Monitor-dependent point measurement greatly enhances drawing speed and app server efficiency. We don't expect this to change.

Subject: /proc needed?

The necessity and desirability of the traditional UNIX /proc and /dev directories was debated.

Subject: BASH and PS1 expansion

How do you set the shell prompt to display the current working directory? A number of solutions were offered. The cleanest was this (type this in a shell to test it; add it to your .profile when you're happy):

PS1="`pwd`> "

Subject: Better keyboard shortcuts for Edit, etc.

Some folks are frustrated by the keyboard bindings used by Be's text editors. The Home and End keys, in particular, are less than ideal: They put you at the beginning and end of an entire document; some folks would rather they operate on the current line. A repeated-key solution, cribbed from BRIEF, was suggested: 1st Home goes to the beginning of current line, 2nd is the top of the screen, 3rd is the top of the document.

In general, consensus favors user-settable keyboard bindings and "swappable" editors (such that you could use the editor of your choice from within the IDE, for example).

Subject: Message interception

Application A can't intercept system messages intended for application B; nor can you find out which window the cursor is over if that window isn't yours. A call for both features was made. The utility of the get-me-the-window feature was questioned: What could application A *do* with application B's window? After an initial muddying of objects and pixels, an answer was offered: Application A could send a message to the "foreign" window.

Subject: What about the desktop?

It was suggested that the Browser allow icons to be left on the "desktop" (a la the Mac). But does a desktop filled with icons look too cluttered? As an alternative, the dock could provide "drawers" for storing multiple icons (this would replace the current dog-eared stack of icons).

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.