At 10:07 AM 11/24/2002, [EMAIL PROTECTED] wrote: >Let me make myself clear. I haven't expressed an opinion about whether >they should or should not be incomplete. I have stated why incomplete >types were originally used in APR, namely for portability.
Some of us interpreted (rightly or wrongly) that they benefit us in a number of ways. There is more than one [right] opinion on this forum. >I have also said that having MMAPs be represented by anything other >than a void pointer and a size is a bit ludicrous. Then you clearly don't understand the implementation. Win32 must retrieve page-aligned file blocks. That means that the real pointer to the mmap allocation is not the boundry the user requested, because we backspace to the last boundry when mapping the region. Then we give the user a pointer to their desired offset. Worse yet, the mmap is not the base kernel object. All mmap's start their lives with a handle to a mapping. With that handle to the mapping, we then map any desired pages into memory. So your offset/length assertion is, simply put, somewhat bogus. We cannot even release the allocation given that original offset/length, on Win32 we must release the page-aligned region, then the mapping handle. I'll skip your other comments as they aren't germane to a portable mmap implementation. >I thought of this a few months ago, but I have been sitting on it while we >try to get 1.0 out the door. This is my vision for how APR 2.0 will be >implemented (I was going to propose it to the list after 1.0 had been >released). This makes the API cleaner and smaller, because many of the >accessor functions can cleanly be deprecated (Think all of the userdata >functions). It also solves a lot of problems with apr_proc_t's on >Windows, where we don't have anyplace to store OS specific information. > >When I said a few days ago that I had hoped that many of the incomplete >types would go away in APR 2.0, this is what I meant. I don't think we >should re-write APR 1.0 now, but if you are going to change MMAPs, then >please let's do it the right way. Your "one right way" seems to be at odds with other's interpretations. I'm not arguing that exposing incomplete types wouldn't speed up APR. In fact, well written accessors that are inline'able on all modern compilers would be a beautiful thing. They would work only for 'private' copies of the apr library, since the app becomes permanently bound to the explicit version installed at the time you build it. That would be fine by httpd and other consumers who don't mind building APR themselves, or for apps that are built via one of the packaging tools that tracks dependencies, and will rebuild the entire slew of dependent packages when a new version of APR is installed. Of course, this won't work for deployment across different platforms. By committing to unwrapping all of the opaque types, you seem hell bent on ensuring we forever break binary compatibility. Opaque types are goodness for versioning, portability, and extensions of the APR library to other languages (e.g. tcl, perl, java etc, especially those with OO schemas). We (you especially) did a passable job of making APR map very well to OO schemas. Please consider their benefits of opaque types before we make plans to wipe them out. Bill
