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."
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?
Disconnect and self-destruct, one bullet at a time.
The mission of the Apache Portable Runtime Project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behavior regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features.
This is competition for java?
Sorry... can somebody give me some insight on what this is?
Does anyone know why Apache didn't just use glib?
This is a C library that provides cross-platform compatibility with respect to file IO, threading, and other fundamental actions. It is not a virtual machine!
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."
md5sum
d41d8cd98f00b204e9800998ecf8427e
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.
> 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..
Do daemons dream of electric sleep()?
First of all, APR is not a virtual machine or bytecode interpreter like that of .NET common language runtime or JVM. APR is a library (collection of functions) written in C, for C programs. It contains a lot of wrappers to the real standard C library functions, because some conventions of standard library still varies from OS to OS.
For example, the path separator is different in Unix ("/"), Windows ("\"), MacOS (":" - pre X, but also Finder in OS X). Another example is loading dynamically linked libraries (DSO in APR speech). Yet another example is threads.
Besides wrappers, APR has its own memory management routines. APR also adds utility functions not found in the standard library, such as hash table.
By the way, it would be helpful if someone can post a comparison between NSPR (netscape portable runtime) and APR.
I once had a signature.
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.
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
For the win32 version of condvar, I don't think a win32 Event isn't going to hack it. The current logic allows a condvar to remain signaled until the all waiters have woken up and have decremented the use count to zero. This could lead to a lot of spurious wakeups if some waiting thread takes it time to wake up. The APR authors need to read that Schmidt document I mentioned earlier and maybe also look at Schmidt's ACE project and see how he did it.
This is not a comprehensive critique as I only took a cursory look but what I did see indicates that APR needs some more work.
---
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...
---
Well, I and others have built HTTP servers using just the sockets provided in wxWidgets - and it's not that difficult.
As for email - you've got wxSMTP
http://www.frank-buss.de/wxwindows/
Also, one of the core developers wrote an entire cross-platform e-mail program with it
http://mahogany.sourceforge.net/
In addition, wxWidgets supports everything you mentioned except video - however, there is a lot of development in that area at the moment... there is a contrib that does this for windows, and there are already a couple of competing libs to do it on mac - linux of course is a different story since native libs don't support it.
In fact, if you use it with allegro (alleg.sourceforge.net) you have a fairly complete solution for pretty much anything.
I think you've got that backwards. APR requires gmake, automake, autoconf and libtool to build. You can build those things without APR.
apr-0.9.4_9
The Apache Group's Portability Library
Maintained by: rodrigc@crodrigues.org
Requires: autoconf-2.59_2, automake-1.8.5_2, expat-1.95.8, gettext-0.13.1_1, gmake-3.80_2, libiconv-1.9.2_1, libtool-1.5.8, m4-1.4.1, perl-5.8.5
APR and GLib have slighlty different design goals. GLib is the low-level of GTK (desktop environment) and APR is the low-level library of Apache 2 (server-side).
So APR was designed to work in servers: it has support for memory pools, filesystems routines, network lacking in GLib. But GLib has support for GObjects, signals which are used heavily in GTK.
So if you're writing a portable server-side application in C/C++ then APR is for you.
PS: Subversion (the great VCS) uses APR.
Unfortunatly g++ is not a good c++ compiler so all the Unix nerds look at the size of the compiled program and time to execute and assume the problem is with C++ itself and then continue to work in C.
There is alot of anti c++ sentiment in the unix community because of that.
http://saveie6.com/
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
Scott Stevenson
Tree House Ideas
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.
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
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).
Ewige Blumenkraft.