APR 1.0.0 Goes Gold

cliffwoolley writes "After several years of development, the Apache Portable Runtime, which is the portability library underlying the Apache HTTP Server 2.x, has finally reached its own 1.0.0 release. If you want to write a portable app without the headaches, APR is the way to do it. Grab a copy and check it out. The full announcement is here."

Comments

APR

[cbrocious]

APR is quite interesting, but there are many existing libraries out there that duplicate the features. Any comparisons out there between APR and things like SDL?

Re:APR

[Anonymous Coward]

Other notable portable runtimes include:

NSPR (Netscape Portable Runtime) http://www.mozilla.org/projects/nspr/index.html

ACE (Adaptive Communication Environment http://www.cs.wustl.edu/~schmidt/ACE.html

wxWidgets http://www.wxwidgets.org

Those are just a few, there are others out there as well

Choosing one to use is a difficult exercise. The important things to consider are what you want to use it for and how it fits in with your existing software and experience.

If you'll be doing GUI programming, wxWidgets is a good way to go. In addition to the file io/threads/networking portability you get GUI portability as well. The NSPR fits into this area as well.

The APR is obviously a well tried and proven framework, since the Apache HTTP server uses it. If you want cross platform server software, APR is probably a good choice. NSPR fits in this area as well.

The biggest consideration when choosing one of these libraries is how well you can pick it up and understand it. If you look at the API and it doesn't make any sense to you, it won't be pleasant to integrate with it. Documentation varies in quantity and quality. Also, how well supported is the library by the development community?. (Actually not much of an issue for APR,NSPR and wxWidgets as they are all very actively maintained and used).

On another note, it certainly would be nice to get more of a standardized set of cross platform libraries on the scale of the Java API. There's no reason why this can't be done. Most of the pieces are already out there. It's too bad someone hasn't yet taken the effort to integrate all of this stuff into a super library for GUI, networking, io, threads, email, video, blah blah blah...

Perhaps I'll have to get started on that...

glib?

[JamesKPolk]

Does anyone know why Apache didn't just use glib?

Re:glib?

[Anonymous Coward]

APR is a library which, at its basic level, provides wrapper functions to syscalls of many different operating systems. Why? because the same syscall on one OS sometimes behaves differently, have bugs, or take slightly different arguments from the same syscall on other OSes.

All true. But you didn't mention the other huge thing it does - pools. They're a completely different way of managing memory than other systems use. The Apache people would say they're higher-performance (more locality -> better cache behavior, big groups of stuff can be deallocated at once, etc.), less error-prone (fewer leaks), etc.

And then a bunch of pool-using code. Like string functions that replace the standard C strcpy() and such but return new pool-allocated strings rather than potentially overflowing a buffer.

Usefull...

[doublebackslash]

I think this is a rather bloody usefull thing, it seems to relate to specific things beyond the stdlib. This would allow c-programers to have an open and completely portable library for all of their applications specific to apache webservers. I think that this is a great idea. I could test a module on my linux box, and then take the souce to my bsd webserver and compile without a hitch, and with a guarntee of it working.
That is a vauge example, but I can see the use in this, and if it becomes common it will be trivial to move web apps between servers, upgrades, etc.
I like this, they aren't trying to give us a whole new language to use, but instead a tool to use with our other existing tricks and tools.

Also the quote on the botom of the page is quite appropriate, "My folks didn't come over on the Mayflower, but they were there to meet the boat."

Yipee!

[Ann Coulter]

Subversion finally has a fully stable base if I'm not missing anything. The prerelease of APR has been giving me headaches when I have to install Subversion. Hopefully, Subversion will make another patch release soon.

apr_pool_t

[multipartmixed]

> Does anyone know why Apache didn't just use glib?

Does glib provide pools-based memory allocation for all its functions?

Somehow, I doubt they do. To me, a good pool-based allocator that handles *everything* is really, really, really freakin' handy. Not only is it cross-platform, but code tends to suffer from fewer memory-allocation-related defects (such as using freed pointers, leaking core, leaking descriptors, etc).

Of course, you have to design your code properly from the outset to take full advantage of hierarchical pools. Apache 1.3 (and presumably 2.x -- I haven't studied the source) are *excellent* examples of code designed to take advantage of pools, and the HTTP request model is almost naturally suited for it as well. Write a few complex modules in C some time, you'll see what I mean.

Now, if only I could could figure out why the APR hash functions are so slow for large tables..

Multi-threading isn't that simple

[xyote]

The atomic operations while nice are basically useless without memory visibility rules or semantics. This is something that get discussed a lot on comp.programming.threads. I suppose you can assume they are there but that's assuming a lot.

Also, doing condvars on windows isn't that easy as Douglas Schmidt writes up here.

Writing portable thread libraries seems to be a popular activity. It would be nice if the authors of those packages documented that they were aware of the issues as a first step in convincing those of us who know about those issues that they know what they are doing. Yeah, I know that the Apache authors are considered experts, but it wouldn't be the first time some rather well known experts got tripped up on multi-threading.

Interested, but confused by Apache License 2.0

[Anonymous Coward]

I'm interested in using the library but confused by the terms of the license.

If I *statically* link to the APR in a commercial software product, what are the consequences? Especially when the commercial software is distributed in binary form only.

http://www.apache.org/licenses/LICENSE-2.0

Re:Some info on APR ...

[xfilez2]

What about ACE (ADAPTIVE Communication Environment)? It's in C++ (ok, perhaps some prefer C), has lots of added features, and has a really less sadistic license..

Like Core Foundation?

[TheInternet]

I looked through the API reference for about 15 minutes -- it reminds me of Apple's Core Foundation. Not that I think they copied Apple, but there are some interesting parallels.

- Scott

Re:Yet another library for an obsolete language

[Anonymous Coward]

C++ suffers from all the memory bugs of C, because it allows all the same things.
A good C++ programmer wont use those things, just like a good C programmer wont do stupid stuff in C.

But C++ is not inherently safer than C, it's just as dangerous as C and has the added bonus of being complicated, unweildy and inconsistent.

Pools have problems (was Re:apr_pool_t)

[Ristretto]

Ugh. Although pools are plenty useful, they have lots of problems. The inability to free individual objects can be a real deal-breaker. Since you can't free objects within a pool until all of them are no longer in use, dead memory can just accumulate. For lots of reasonable situations, this means unbounded memory consumption. It also makes it very hard to incorporate existing code that uses malloc/free.

I wrote a paper about this, and problems with custom (special-purpose) memory allocators in general, called Reconsidering Custom Memory Allocation (OOPSLA 2002). In it, I also describe a new memory allocation scheme, called reaps . This is a hybrid of regions (pools) and heaps that acts just like pools except you can still free individual objects.

In fact, for a case study, I put reaps into Apache (adding a ap_pfree call), and showed how using reaps made it simple to incorporate a piece of existing C code (namely, bc) into Apache. Without reaps, an invocation consumed 7.4MB of memory (since every free had to be disabled). With reaps, 240KB.

I did send a message to the Apache folks about this a while back, but they balked because the implementation is in C++, rather than C (developed with my Heap Layers infrastructure)...

-- emery

Emery Berger
Assistant Professor
Dept. of Computer Science
University of Massachusetts, Amherst

Re:Yet another library for an obsolete language

[qbwiz]

Unfortunately, a problem with g++ is (for Linux developers) a problem with c++. There aren't many alternatives, so while g++ may not be a shining example of how c++ can be, it's a good example of how it is. It makes sense to consider the available compilers when deciding whether to use the language (and also partially when bashing the language - if it's impossible to write a good compiler for, it's likely to be hard to write code in - due to complexity).