Slashdot Mirror

← Back to Stories (view on slashdot.org)

APR 1.0.0 Goes Gold

Posted by michael on from the run-anywhere dept.

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."

111 comments

  1. I've been using for some time now by Anonymous Coward · · Score: 0

    It's a great set of libraries called 'glib' and 'gnet'. Perhaps you've heard of them:)

    1. Re:I've been using for some time now by Cyberax · · Score: 3, Informative

      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.

    2. Re:I've been using for some time now by E_elven · · Score: 1

      APR saves one from quite a few headaches, but it's a large framework and takes time to learn. I really wish they'd just implemented it with a POSIX interface.

      One thing APR is not good for is interaction with other compatibility frameworks: I've been hacking together a Ruby API for Subversion VCS and it's been a bit of a pain to integrate because of the memory allocation.

      --
      Marxist evolution is just N generations away!
    3. Re:I've been using for some time now by Billly+Gates · · Score: 1

      If they tried the posix interface than it would not be compatible with Windows, VMS, and Vxworks.

      I am guesing APR is not just for someone who wants to write a custom quick webserver but also for appliances and devices. Most embedded hardware runs custom os's.

      My guess is with APR we are going to see custom httpd's from everything to Atari's to old Newtons.

      --
      http://saveie6.com/
    4. Re:I've been using for some time now by E_elven · · Score: 1

      No, I meant that the interface should have implemented POSIX calls for simplicity, except where a functionality isn't defined in POSIX.

      --
      Marxist evolution is just N generations away!
    5. Re:I've been using for some time now by Anonymous Coward · · Score: 0

      The problem is that POSIX semantics aren't going to be available everywhere, otherwise you could just use one of the various POSIX emulation libraries that are available (Cygwin is essentially one). Rigidly providing full POSIX semantics is inappropriate for applications that can accept some leeway in behavior.

      Beyond this, you wouldn't want a third party library implementing POSIX calls, for obvious namespace collision reasons. And if you add an apr_ to the POSIX calls, and only do so when the calls overlap in functionality, then you still need to consult the documentation anyway.

      I can think of two examples of where using POSIX-style calls would be inappropriate. First, I/O routines in POSIX make extensive use of integer file descriptors. These don't port over very well to Windows (the Windows socket API has to use a whole new data type called SOCKET because the WinAPI idea of a file descriptor isn't compatible). Then you have pthreads, which are very handy, but extremely difficult to emulate on Windows (although there have been some attempts towards Win32 pthreads APIs, they're far from perfect and their performance sucks because they need to be able to handle special cases where the Win32 and POSIX behavior match up very poorly). The pthread APIs also make use of attribute objects, which may or may not be appropriate to emulate in a portable runtime. Another thing about the APR APIs is that they make extensive use of memory pools, which completely changes the way you'd want to design an API. (How many times have you had to consult a man page to check if a POSIX function allocates memory, wants a block of allocated memory, can or can't take a block of allocated memory, etc.?)

      Anyway, the POSIX APIs provide an interface which is certainly useful, but they're far from portable to any operating system which diverges in implementation substantially from UNIX. Microsoft's POSIX subsystem (available separately from Windows) is implemented just above the NT kernel, at the same level as the Win32 subsystem. This kind of access isn't the sort of thing available to Win32 applications running on top of the Win32 subsystem.

      The lame thing is, almost all operating systems on all platforms, from dinky embedded devices to supercomputers, export POSIX interfaces. POSIX has only not been common on the desktop with Windows and Macintosh, and since Apple moved to OS X, Windows is the last real hold out, which means you could program to POSIX and have a reasonable expectation of your code porting easily enough to any platform, except for Windows. Anyone who's still waiting for the Win32 versions of some useful piece of server software (PostgreSQL 8.0 vs. MySQL, Apache HTTPD 2.0 vs. IIS) to come out can likely understand the frustration involved.

  2. APR by cbrocious · · Score: 4, Interesting

    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.
    1. Re:APR by Electrum · · Score: 4, Informative

      Any comparisons out there between APR and things like SDL?

      APR is for servers, SDL is for games.

    2. Re:APR by FooAtWFU · · Score: 4, Insightful

      I don't think APR and SDL have much of the same market. The Apache Portable Runtime is used in the Apache httpd. Simple DirectMedia Layer is used for graphics and sounds and the link.

      --
      The World Wide Web is dying. Soon, we shall have only the Internet.
    3. Re:APR by cbrocious · · Score: 4, Informative

      But SDL provides cross-platform threading and such. It's been used in many things other than just games (which is why it's not just sound and video)

      --
      Disconnect and self-destruct, one bullet at a time.
    4. Re:APR by Anonymous Coward · · Score: 5, Interesting
      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...
    5. Re:APR by eille-la · · Score: 1

      I'd also like to know how much and in which ways it differs from wxWidgets

    6. Re:APR by Anonymous Coward · · Score: 2, Informative

      Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."

      Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, RISC OS, and SymbianOS.

      SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, Eiffel, Java, Lua, ML, Perl, PHP, Pike, Python, and Ruby.

    7. Re:APR by Anonymous Coward · · Score: 3, Funny
      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.

      Do you mean something like Java?

    8. Re:APR by Anonymous Coward · · Score: 0

      Don't mention the link and then forget to include it!

    9. Re:APR by Goo.cc · · Score: 2, Funny

      Sometimes, I think that Sun itself is the greatest problem facing Java.

    10. Re:APR by Anonymous Coward · · Score: 2, Informative

      NSPR, ACE, and the wxWidgets toolkit are all for C++. APR is for C. About the only thing that comes close is glib, and it's actually a pretty poor fit on non-unix platforms.

    11. Re:APR by BaldBass · · Score: 3, Informative

      BOOST certainly deserves mention

    12. Re:APR by borud · · Score: 1
      The biggest consideration when choosing one of these libraries is how well you can pick it up and understand it.

      Indeed. Important observation.

      In addition most libraries impose a way of doing things that might not fit your application. In the C/C++-world this situation often arises. For instance you might want to use two libraries together, that both need to be in charge of thread- or signal handling etc, so you end up kludging together the bits you need and it never feels quite right.

      Then, of course, it is the eternal C versus C++ choice. A lot of software platforms (like apache) are in C, and thus integrating with C++ is a major pain. Not to mention the pain of absorbing libraries into other programming languages like Perl, Python, PHP or Java.

      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.

      I don't think it can be done. At least not without an influx of new, bolder and smarter people than the current custodians of C++.

      If you look at Java, you have a rather well-defined runtime environment, the process by which additions to the Java standard library are made is slow and deliberate. There is a *lot* of focus on doing things correctly and making sure it is efficient. Some really brilliant people work on Java, and most importantly: because they are so thorough and their stuff works before they declare it a standard part of Java you can build new things on the shoulders of others.

      Now look at C++. Not even the first row of building blocks is properly into place like a proper collections framework. STL isn't really it since for non-trivial uses it quickly gets ugly and even seasoned C++ hackers make beginner-mistakes. Also the static code generation paradigm is inelegant, unflexible and, given enough abstractions stacked on top of each other, really hard to work with when something goes wrong.
      Without even having a good foundation to build upon, there is little hope that C++ will ever have higher level APIs as part of the standard APIs. You won't see things like networking, concurrent processing, filesystem interfaces, proper internationalization, encryption, XML parsing as a standard part of C++. Or even C for that matter. But you will see a lot of initiatives like APR. And glib. and ACE. And mixing and matching the parts you like will be a serious pain in the neck.

      In fact, most people would say that these have no business being part of a language, but I think that Java has proven quite well that it needs to, or else, you will severely limit the development and inclusion of further useful abstractions.

      It is all in the foundations and the given environment's definition of what is part of it and what is not.

  3. java-ish? by BoldAC · · Score: 3, Insightful

    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?

    1. Re:java-ish? by dollargonzo · · Score: 4, Informative

      this a C library, not a virtual machine/language like jvm/java. the idea is not to have code run without recompile on all platforms, but rather that *all* you need is a recompile. more specifically, you don't need to have platform specific cases in your code. code becomes pretty unmaintainable when it is littered with #ifdefs

      --
      BSD is for people who love UNIX. Linux is for those who hate Microsoft.
    2. Re:java-ish? by hey · · Score: 1

      A portalable runtime (like the APR) would be a good place to start if you were going to write a Java interpreter.

  4. Neat! by jonesboy_damnit · · Score: 1, Insightful

    Hooray for compatibility layers!
    ...I wonder what the performance of this stuff is like as compared to Java. My knee-jerk reaction is "wow, it should be much faster!", but I suppose time will tell. Could make for some interesting new PHP/JSP/etc. type things, or wider compatibility for them.
    Of course, it may also remain relatively obscure and unused. Given the attention they've paid to detail on it, that would be a shame, imho.
    -Matt

    1. Re:Neat! by Anonymous Coward · · Score: 0

      You have absolutely no idea what APR is, do you?

    2. Re:Neat! by jonesboy_damnit · · Score: 1

      Wow, that's an unwarranted response. Given that it's an Apache project, my immediate thoughts for its use were Apache-centric.
      I didn't suggest that it was a virtual machine. In fact, in my post, I clearly identified it as a 'compatibility layer', which is exactly what it is.
      Doesn't anybody read anything on Slashdot before posting? Are the Slashdot forums just a bunch of people trying to post/mod/etc. as quickly as possible in a ridiculous attempt to collect karma?
      *sigh*
      -Matt

    3. Re:Neat! by silas_moeckel · · Score: 1

      Yes

      With few exceptions. You would wonder if they shouldent just code some fame to bring up the primary linked site with a 30 second timer before they can read or post to the forums.

      Realy though all this java talk dosent make a whole lot of sence besides posiby for people that think everything should be java and never have had to write something on a memory constrained system or in assembly.

      --
      No sir I dont like it.
    4. Re:Neat! by Anonymous Coward · · Score: 0

      If you understood what APR was about, you wouldn't have talked about PHP/JSP.

    5. Re:Neat! by jonesboy_damnit · · Score: 1

      Right, because PHP and JSP aren't interpreted languages that require a binary layer below them in order to do anything. Those binary layers also don't need to be ported from platform to platform, and introducing new features that work fine on one platform and don't work fine on the others *never* happens.
      Once again - initial knee-jerk thoughts were Apache/Web-centric, naturally there are a thousand million other applications that could benefit from such a library.
      Trolls... dunno why I bother responding.
      -Matt

    6. Re:Neat! by tepples · · Score: 1

      You would wonder if they shouldent just code some fame to bring up the primary linked site with a 30 second timer before they can read or post to the forums.

      That would only make the Slashdot effect even worse.

  5. glib? by JamesKPolk · · Score: 3, Interesting

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

    1. Re:glib? by DylanQuixote · · Score: 5, Informative

      glib didn't exist at the time the APR was started. Also glib is still not quite useful on windows.

    2. Re:glib? by E-Lad · · Score: 4, Informative

      You have the wrong idea of what APR is.

      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.

      APR addresses these differences and provides you, the app developer, with a common set of functions.

      So if you're say coding your own FTP server project and you main development platform is linux or what have you, if you use APR's wrtite() or APR's sendfile(), you know that your call to that will also work on Solaris, FreeBSD, Darwin, etc... because APR takes care of all the abstraction at compile time. /dale

    3. Re:glib? by Junta · · Score: 3, Informative

      That is *exactly* the sort of stuff glib was intended for, to wrap system calls on specific platforms and provide a cross-platform API for basic syscalls. It was the low-layer abstraction of cross-platform things GTK/GDK needed, and has grown from there.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    4. Re:glib? by cyfer2000 · · Score: 1

      does glib distribute with GNU license?

      --
      There is a spark in every single flame bait point.
    5. Re:glib? by Anonymous Coward · · Score: 5, Interesting
      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.

    6. Re:glib? by noselasd · · Score: 1

      sort of like g_strdup or g_strdup_printf. Btw glib provides something similar

    7. Re:glib? by Anonymous Coward · · Score: 0

      It's hard to put a finger on it, but Glib is not a commercial-grade code. It looks like an evolution of a college term project, or someone's 'utility library', which any experienced developer would have. And since it wraps up basic things, which I'm supposed to use as a foundation for my code, I would expect it to have less fancy naming notation, not to have a zillion variations of list_add() function and do few other things differently to fit my programming preferences. Since there's no fit - bye bye glib.

    8. Re:glib? by Anonymous Coward · · Score: 0

      "Also glib is still not quite useful on windows."

      Actually, glib works quiet nicely on windows.

      http://www.gimp.org/~tml/gimp/win32/

    9. Re:glib? by Anonymous Coward · · Score: 0

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

      Because apache includes APR directly, not just as a DLL, and thus doesn't want to become infected by the LGPL.

  6. It is NOT java! by damm0 · · Score: 3, Informative

    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!

  7. Usefull... by doublebackslash · · Score: 2, Interesting

    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 /boot/vmlinuz
    d41d8cd98f00b204e9800998ecf8427e /boot/vmlinuz
  8. Yipee! by Ann+Coulter · · Score: 3, Interesting

    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.

    1. Re:Yipee! by jjon · · Score: 1

      > Subversion finally has a fully stable base if I'm not missing anything.

      You're missing that APR 1.0.0 is not compatible with APR 0.9.x.

      So Subversion cannot upgrade to APR 1.0.0 without breaking binary compatibility, which the Subversion people have guaranteed not to do before Subversion 2.0.0.

      Also, Subversion depends on the Apache web server, so it must use the same version of APR as the Apache web server. AFAIK the web server is still using APR 0.9.x.

    2. Re:Yipee! by breser · · Score: 3, Informative

      Actually Subversion trunk can already build against APR 1.0.0. We had a lengthy discussion about this a while back. I'm not sure we ever really resolved it. But the general consensus seemed to be that enforcing majors of our dependency to always be the same wasn't something we were enforcing binary compatability for.

      I.E. Subversion's compatability guarantees are only good to the degree that you don't go changing major versions of the libraries.

      You are correct that Apache 2.0.x will continue using APR 0.9.x, but Apache 2.2.x (currently called 2.1.x) will use APR 1.0.0. If we enforce the major of APR we can only function with Apache 2.0.x, which is not a requirement we really want to limit ourselves to.

    3. Re:Yipee! by cpeterso · · Score: 1


      While thinking about version numbers, I wonder what awaits us in APR 2.0? Most of the common portability concerns seemd to have been wrapped up pretty well in APR 1.0 (for the basic features Apache needed). What's left?

      --
      cpeterso
  9. apr_pool_t by multipartmixed · · Score: 4, Interesting

    > 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()?
    1. Re:apr_pool_t by JamesKPolk · · Score: 1

      That's exactly the kind of answer I was hoping for. Thank you.

    2. Re:apr_pool_t by short · · Score: 1

      In glib2 just set your own GMemVTable by g_mem_set_vtable() such as by g_mem_chunk_*() set of functions (=pool allocations).
      I see APR as a dupe, the same as NSPR or non-graphical part of Qt.
      They at least try to provide some generic portability/utility layer, most of the projects just reimplement it always from the scratch for themselves.
      Your "Not only is it cross-platform, but code tends to suffer from fewer ..." sentence is not related to the GLib vs. APR question at all. Otherwise clarify it.

    3. Re:apr_pool_t by alder · · Score: 1
      ...why the APR hash functions are so slow for large tables..
      Last time I looked - about a year ago - they (APR hash functions) weren't really hashed. They are (were?) arrays of key-value pairs. Hence the slow lookup...

      P.S. Oh, they can be called hash tables, though with a hash function that returns the same value for all its keys ;-)

    4. Re:apr_pool_t by johnnyb · · Score: 1

      Apache's pools are pretty cool. You can also do the same thing with GNU's obstacks.

      --
      Engineering and the Ultimate
  10. Some info on APR ... by pikine · · Score: 5, Informative

    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.
    1. Re:Some info on APR ... by DrXym · · Score: 4, Informative
      The NSPR offers similar functionality. Info about the NSPR is here.

      I'm guessing by this stage that both the APR and NSPR are industrial strength libs to write cross-platforms against. Both have similar functionality because both underpin web servers (yes NSPR is used by the AOL/Sun iPlanet webserver, and not just Mozilla).

      What it might boil down to in the end is which runtime's licence is most compatible with what you have in mind.

    2. Re:Some info on APR ... by xfilez2 · · Score: 3, Interesting

      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..

    3. Re:Some info on APR ... by edesio · · Score: 2, Informative

      Another interesting site is Accelerating Apache Project. I don't know why this approach was rejected by the Apache Group. I used their State Threads Library with success.

    4. Re:Some info on APR ... by RTMFD · · Score: 1

      In my experience, ACE is really nice, just stay away from TAO as it has little to no _good_ documentation (except for the doxygen stuff and the tutorials). I must say that I've been impressed with ACE though. Perfect for _real cross-platform coding_.

    5. Re:Some info on APR ... by cpeterso · · Score: 1


      After Firefox 1.0, Mozilla should consider ditching NSPR for APR. The engineering and QA time spent on NSPR (which is pretty much done/frozen) can be redirected to APR. That work would benefit the open-source community, but Mozilla would also benefit from other people fixing bugs in APR. :D

      --
      cpeterso
  11. Did they just say? by HenryKoren · · Score: 0, Flamebait

    Did they just say "entirely in C" and "assured of predictable behavior" in the same context?

    o_0

    The only thing better than writing everything in C is how it supports BEOS and OS/2!

    on freebsd 5.2.1.... APR is required to build:
    devel/gmake
    devel/automake18
    devel/autoconf259
    devel/libtool15

    so I guess most people don't even realize that APR is one of the fundamental building blocks of all open source applications.

    Its too bad it only incldes basic low-level data structure functionality so far.

    list of all APR modules

    But then again I guess that's the point of this project. Anything to make C coders lives easier is a good thing!

    --
    To blog is sublime
    1. Re:Did they just say? by toastyman · · Score: 3, Informative

      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

  12. Multi-threading isn't that simple by xyote · · Score: 5, Interesting
    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.

  13. Re:Yes, but... by Resident+Maniac · · Score: 1
    Does it run Linux?
    Since it's an app, wouldn't the correct troll question be "Does it run on Linux?"
    --
    "Life isn't about the number of breaths we take; it's about the moments that take our breath away. Like choking."
  14. Interested, but confused by Apache License 2.0 by Anonymous Coward · · Score: 4, Interesting

    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

    1. Re:Interested, but confused by Apache License 2.0 by DarkMan · · Score: 3, Informative
      Disclaimer: Your not paying for this; this is not legal advice. For that, contact a lawyer in your juristriction.

      By my reading of the liscence, it makes absolutly no distinction between static and dynamic linking. Therefore, the only way that it could cause a difference is within the definition of a 'derived work'. To quote the licence:

      "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.


      If you link, or bind by name, to the interfaces of the Work, then your code is not a derived work. Thus, the only applicable terms in the licence are those that govern use and distribution of the code. The licence grants you the right to distribute in source or object form the work.

      Accordingly, my reading is that this is semantically virtually equivlent to the BSD licence for case specified (and, in fact, the same as BSD for pretty much any case of use and distribution).

      Short answer: Stick a mention of it in the NOTICE text file, tell people what liscene the Work (in this case the APR) was under, and go ahead.

      Interestingly, this licence would, as I read it, allow you to make a derived work, and redistribute that in binary form only. It doesn't grant you the right to change liscence, or apply restrictions, so a Derived Work wouldn't work as a commerical product (as the first purachaser can redisribute it).

      But, as it specifically excludes linking to the interfeces specified, then for a Work which is a library [0], the only clause that imparts any restriction is 4(d) [1]

      In fact, I can see no part of the liscence that would prevent one from taking a program under this liscence, creating a Derived Work that is that program implemented as a library, with well defined interfaces, and then linking to said library from a commercial/closed program. There is no requirement to publish Derived Works [2]. The only mildly non-obvious outcome is that if the library was extracted from the final disribution, the licence allows for its free distribution and use, which is not a restriction.

      Of course, if this is for commerical software, you'll have the money to speak to a lawyer licence to practice in your juristriction first.

      [0] And where that library is used unmodified
      [1] And the expiration of patent licences in event of you issuing a patent suit.
      [2] Only that you make any changes clear if you do publish.
  15. Mirrors by Anonymous Coward · · Score: 0

    Download here:
    http://www.apache.org/mirrors/ /RH

  16. Follow up - I took a quick look at the source. by xyote · · Score: 5, Insightful
    For the atomic operations, the intel based code is ok since the lock prefix serializes memory. The powerpc load reserved / store conditional do not however and explicit memory barriers are required and they are not there. That's bad.

    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.

    1. Re:Follow up - I took a quick look at the source. by MenTaLguY · · Score: 1

      You may want to consider filing a few bugs or something to bring these issues to their attention, if you've not done so.

      Dropping a link to Schmidt's work in there might not be a bad means of stealth education, either.

      --

      DNA just wants to be free...
    2. Re:Follow up - I took a quick look at the source. by NoMercy · · Score: 2, Insightful

      Please, if your comments are creative, and useful, forward them to the team who are doing it (give them plenty of easy links to the resources so they don't instantly dismiss you).

      I don't know enough in this field to help, but if somone sent me some details on any project I'm working on which allows me to improve it, I'd be greatful, though not likely to give you pizza tokens :)

    3. Re:Follow up - I took a quick look at the source. by alder · · Score: 1
      For the atomic operations, the intel based code is ok since the lock prefix serializes memory.
      Well, yes, that is true, but only for uniprocessors or Pentiums. P5 is a strongly-ordered architecture. Unfortunately this is not the case for P6, which are weekly-ordered, and hence for multiprocessors require much more expensive synchronization - typically LOCKed CMPXCHG that is followed by CPUID.
  17. Super Library(Re:APR) by Anonymous Coward · · Score: 2, Informative

    ---
    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.

  18. Re:Yes, but... by Anonymous Coward · · Score: 0

    That'd make too much sense, though.

  19. Which license are you referring to? by jbn-o · · Score: 1

    There is more than one GNU license -- the GNU General Public License, which disallows proprietary derivatives, and the GNU Lesser General Public License, which allows proprietary derivatives. Then there's the GNU Free Documentation License which is intended for something else.

    If you meant a license the Free Software Foundation calls a "free software" license, then there's even more licenses to consider. All this raises the question: which license are you referring to?

    --
    Digital Citizen
  20. Yet another library for an obsolete language by njdj · · Score: 1, Troll

    I know I'll get flamed/modded down for this, but it needs to be said: there is no reason for new apps to be written in C. C++ can do everything that C can do, just as efficiently; it's easier to read, which means a code review is more effective; language features and the STL reduce the need for explicit dynamic memory allocation, which is a source of bugs in C; the language is a better match than C to modern, object-oriented methods of analysis and design; - I could go on, but shouldn't need to.

    1. Re:Yet another library for an obsolete language by Billly+Gates · · Score: 4, Informative

      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/
    2. Re:Yet another library for an obsolete language by Anonymous Coward · · Score: 1, Insightful

      And that's not even the half of it... take a look at this:

      http://tinyurl.com/605v

    3. Re:Yet another library for an obsolete language by quigonn · · Score: 0

      First of all: there are many reasons for new apps to be written in C. One is portability: when you write portable applications for Unix, you can basically only assume that you have C available. Another one is bloat: C programs are generally less bloated than their C++ counterparts. STL is one reason: while STL provides a pretty generic framework, it leads to hidden (i.e. only visible in the binary code but not in the source code) code duplication. Less bloat also means less code cache misses.
      And in case you missed it: it _is_ possible to do object-oriented programming in pure C. While it can look ugly and the language doesn't explictly support it, it isn't too difficult to implement. So you can do use your modern design methods, and still implement it using pure C.

      Oh, BTW: your argument with explicit memory allocation is totally flawed: in fact, when using C++ you have to care as much as you have to care using C. Trust me, I know what I'm talking about, I currently do C++ programming for Symbian OS for a living, and it's no real fun, especially since C++ on Symbian OS is less forgiving than on a typical Unix or Unix-like operating system.

      --
      A monkey is doing the real work for me.
    4. Re:Yet another library for an obsolete language by Anonymous Coward · · Score: 2, Interesting

      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.

    5. Re:Yet another library for an obsolete language by qbwiz · · Score: 2, Interesting

      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.
    6. Re:Yet another library for an obsolete language by njdj · · Score: 1
      Unfortunatly g++ is not a good c++ compiler

      I disagree; I think the current version is a fine C++ compiler. What's wrong with it?

    7. Re:Yet another library for an obsolete language by tepples · · Score: 1

      Measure the execution time of a typical C++ program as compiled into an executable. It appears that Billly Gates and qbwiz claim that other vendors' proprietary C++ compilers have a much bigger speed gain over g++ than their C compilers have over gcc.

    8. Re:Yet another library for an obsolete language by Billly+Gates · · Score: 1

      THe intel one is very good.

      However many programs like the Linux kernal are hard coded for gnu specific features.

      But for general coding its inexpensive and quite good.

      --
      http://saveie6.com/
    9. Re:Yet another library for an obsolete language by Billly+Gates · · Score: 1

      There is no C++ compiler. ITs a standard. THere are c++ compilers on the other hand.

      MS VC++ is a good one and so is watcom C++ and Borland.

      None are ported to Unix.

      IF you look at the resulted assembly code you will see many many unoptimized code that MS VC++ and Borland would optimize by default.

      --
      http://saveie6.com/
    10. Re:Yet another library for an obsolete language by Anonymous Coward · · Score: 0

      C is the one true language, it's C++ thats obsolete. Modern language's compile to bytecode and run on garbage collecting VM's that are themselves written in C. Did you not get the memo?

      C++ is dead, it was a jack of all trades that did nothing well. Here in the 21st Century we use C for systems programming and a well JIT'd VM for everything else.

    11. Re:Yet another library for an obsolete language by Anonymous Coward · · Score: 0

      I know I'll get flamed/modded down for this, but it needs to be said: there is no reason for new apps to be written in C. C++ [...typical C++ hyperbole...]

      Whether it's true or not, it's irrelevant.

      C++ doesn't offer any of the features of APR. And since C++ can use any C library, if you want to use C++ and the APR together, go right ahead.

      You got modded a troll because you tried to use the APR release as a platform for advocating your favorite language.

    12. Re:Yet another library for an obsolete language by Anonymous Coward · · Score: 0

      There is no C++ compiler. ITs a standard. THere are c++ compilers on the other hand.

      Somebody who capitalizes the "H" of "THere" probably shouldn't be criticizing somebody who capitalizes the "C" of "C++".

  21. Re:first post by ComaVN · · Score: 1

    Yes.

    It is the first post.

    It has "first post" as subject.

    The only content in the post is "first post"

    I think that qualifies as redundant.

    --
    Be wary of any facts that confirm your opinion.
  22. Re:damn by Anonymous Coward · · Score: 0

    OH come on. This is hilarious.

    I just lost another loan to Ditech.com!

  23. Like Core Foundation? by TheInternet · · Score: 3, Interesting

    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
  24. Re:first post by name773 · · Score: 1

    ah, thank you. and here i thought the mods' favourite modifier switched from offtopic to redundant...

  25. GLib by r6144 · · Score: 1
    As other posts have pointed out, what GLib does is mostly the same; although GLib seems to be used mostly in client-side apps, I have written quite a few server programs quite comfortably with it.

    Looking at the API it seems that GLib is a bit easier to use, while APR has some features that may lead to better performance, in particular memory pools (GLib does not have it, so all memory allocation are done by malloc(), saving a parameter but also losing a little flexibility).

    Both are quite complete; but from a quick glance I can't find any data structure in APR that implements a sorted set/map, such as balanced binary trees or red-black trees or heaps, which seems to be quite handy when implementing timeouts (you always need to get the timeout that will expire first in order to provide the "timeout" parameter for "select"). Does anyone know how to solve this problem?

  26. Pools have problems (was Re:apr_pool_t) by Ristretto · · Score: 5, Interesting
    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

    1. Re:Pools have problems (was Re:apr_pool_t) by vranash · · Score: 1

      Considered Sending them a version of it written in C instead of C++? ;-p

      While I understand your complaint, there are a *LOT* of projects with this exact same stance. All code must be written in C. Trying to get them to implement code that will lower their audience (not to mention considering some of the new 'differences' in C/C++ syntax in gcc 3.4+ suddenly dropping a piece of C++ code in not only forces users to have a C++ compiler handy, but also might force developers who are used to C syntax to find themselves stuck figuring out what they have to change now to make their 'proper C' code into proper C++ code.

      Anyhow, my 2 cents.

      -- vranash

    2. Re:Pools have problems (was Re:apr_pool_t) by Anonymous Coward · · Score: 0

      You can mix C++ with C easily as long as the C++ functions are declared as 'extern "C"'. If you read how Berger's memory allocation libraries work you can see that the language the library is implemented in is irrelevant. Indeed, his Hoard library which is written in C++ replaces the operating system's slow malloc/free routines with high speed replacements on Linux, Solaris and Windows - even in programs entirely written in C. The programs have no idea it is even in use. The issue of using C++ in this APR case is not a technical one - it is a social one coupled with a lack of understanding and unwillingness on the part of many people to try something new.

  27. Uses Apache license by avida · · Score: 1

    And I won't be using APR because the Apache license suxors.

  28. Where every byte counts by tepples · · Score: 1

    there is no reason for new apps to be written in C.

    By "new apps" do you mean this to include "new versions of g++" as well? If so, then how would you recommend bootstrapping a C++ compiler on a system with only GCC?

    language features and the STL reduce the need for explicit dynamic memory allocation

    To a developer who has to fit algorithms and data structures into a handheld computer's 32 KB of fast RAM when all other RAM in the system has horrible wait state behavior, every byte still counts. I've read horror stories that use of the STL tends to bloat code size. Have modern STL implementations addressed this issue other than just to deprecate a widely deployed handheld computer?

  29. APR pools make C++ integration difficult by Anonymous Coward · · Score: 0

    I tried to integrate C++ components into the APR framework and eventually gave up because the APR memory pool concept is not very compatible with C++'s memory management scheme. You would have to register callbacks for object cleanup all over the place for every C++ class type in order to get the C++ destructors called. You can do it, of course, but it makes C++ programming painful with APR. As for pool memory locality in APR - it is good for streaming web pages, but not much else. All locality is lost when you are dealing with objects that span multiple HTTP connections.

  30. Where can I find a Reaps patch for APR? by Anonymous Coward · · Score: 0

    I agree that the pools scheme used in APR is completely unusable for integrating traditional C or C++ code - pools are only good for traditional HTTP-like request-response processing. Where can I find an implementation of APR with your Reaps hooks? By the way - your research rocks.

  31. APR not as mature as NSPR by Anonymous Coward · · Score: 0

    NSPR is proven to run on a dozen platforms in the past 5 years. APR is not nearly as mature as NSPR - nevermind that the apr_pool_t concept does not work very well in non-HTTP based multithreaded servers - it wastes too much memory and makes it extremely difficult to integrate traditional malloc/free based code.

    Everyone I know is still playing 'wait and see' with Apache 2.x, and the same can be said for its infrastucture.