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(sem)
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(sem)
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).

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.

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?

• Stable management support is a must. Without it, the best people on the team will be pulled away to put out other fires in the product line.

• A combination of political and technical astuteness is also required. This gets a little touchy. A straight port might be the easiest political sell inside. But technically, and in the eye of the paying customer as well, it might not make the most sense. For the "port" to make technical and commercial sense, a substantial amount of redesign might be required.

• Finally, the project needs a dancer's light tread to balance what must be said and what must be done in order to reach successful completion. Arabesque.

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 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: http://www.be.com/about_be/mailinglists.html.

PS1="`pwd`> "