APR (Apache Portable run-time Librarie) Introduction

Apache Portable run-time librarie

In earlier versions of Apache, the application itself must be able to handle the details of the various operating system platforms and invoke different processing functions for different platforms. With the further development of Apache, the Apache organization decided to separate these common functions and develop them into a new project. 　　In this way, the development of APR is independent of Apache, Apache is only using Apr. Apr is currently used primarily by Apache, but because of the better portability of APR, some C programs that need to be ported are starting to use APR, too. APR enables the processing of platform details to move down. For applications, they do not need to consider the platform at all, whether UNIX, Linux or Windows, the interfaces that the application executes are basically uniform. So for APR, portability and a unified upper layer interface are a key consideration. The first thing that Apr did not do was to merge all the code used in Apache into a common code base, but it was not the right strategy, so the APR changed its goal. 　　Sometimes using public code is not a good thing, such as how to map a request to a thread or a process is platform-dependent, so a single common code base does not complete this distinction. Apr's goal is to securely merge all the code that can be merged without sacrificing performance. One of the earliest goals of APR is to provide a common, unified operational interface for all platforms (not parts), which is a very remarkable goal and, of course, an unrealistic one. We cannot support all the features of all platforms, so APR currently offers all APR feature support for most platforms, including Win32, OS/2, BeOS, Darwin, Linux, and so on. To achieve this goal, APR developers must create a series of feature macros (FEATURE MACROS) to differentiate between platforms for features that cannot be run on all platforms. These feature macro definitions are simple, usually as follows: Apr_has_feature If a platform has this feature, the macro must be set to true, for example, Linux and windows have memory-mapped files, and APR provides an operational interface for memory-mapped files. Therefore, on these two platforms, the APR_HAS_MMAP macro must be set, while the ap_mmap_* function should map the disk file to memory and return the appropriate status code. If your operating system does not support memory mapping, then Apr_has_mmap must be set to 0, and all ap_mmap_* functions may not need to be defined. 　　The second step is to warn about functions that are not supported in a program. Base type files supported in APRFolder name Description atomic/srclib/apr/atomic atomic operation DSO/SRCLIB/APR/DSO dynamically load shared library fileio/srclib/apr/file_io file IO processing mmap/srclib/apr/m 　　Map memory-mapped file locks/srclib/apr/locks process and thread mutex memory/srclib/apr/memory memory pool operation network_io/srclib/apr/network_io Network IO processing Poll/srclib/apr/poll polling IO table/srclib/apr/tables apache Arrays (stacks) and tables as well as hash table Process/srclib/apr/threadproc process and thread actions user/ Srclib/apr/user User and User group operations Time/srclib/apr/time time operation String/srclib/apr/strings string operation PASSWORD/SRCLIB/APR/PASSWD terminal password Handling Misc/srclib/apr/misc Hodgepodge, any APR type that does not belong to the rest of the class can be placed inside Shmem/srclib/apr/shmem shared memory random/srclib/apr/random random number generation Library

Apr analysis-Overall because the department used the underlying library and Apache server has a "certain source", so there is always a desire to see the implementation of Apache impulse. The end of the recent project, the wish can be achieved.

One, what is Apr?

Apache server after so many years of development, will be a number of common Run-time interface packaging to provide to everyone, this is Apache portable run-time libraries, APR.

Ii. the catalogue organization of APR

From the www.apache.org download apr-1.1.1.tar.gz to the local decompression, found that the APR directory structure is very clear.

1 All header files are placed in the $ (APR)/include directory;

2 The implementation of all functional interfaces are placed in their respective separate directories, such as ThreadProc, mmap, etc.

3 In addition, the relevant platform to build tool files such as makefile.in. Once you have seen the ACE code, all of the Ace's source files (. cpp) are placed in a directory, which is confusing. Apr gave me a good first impression.

4 into each functional interface subdirectory, taking ThreadProc as an example, in the following subdirectory there are 5, respectively, BeOS, NetWare, Os2, UNIX and Win32. The name of the APR can also be understood, and each subdirectory is housed with a unique implementation source file for each platform.

Three, the APR constructs

If you want to use APR, you need to build it on a specific platform, regardless of the characteristics of multiple platforms, only for UNIX platform analysis.

1) Relationship between Apr.h, Apr.h.in, APR.H.HW and APR.H.HNW

Under the $ (APR)/include directory, the most basic apr.h files are generated automatically at build time because APR considers portability, where apr.h.in similar to a template as the input source for the apr.h generator. Where APR.H.HW and APR.H.HNW are specific versions of Windows and NetWare respectively.

2 Compile-time considerations

When compiling on UNIX, note that the $ (APR)/build *.sh file access rights, should be chmod first, otherwise make will prompt error.

Iv. Application of APR

Let's start with make install, for example, we specify prefix=$ (Apr)/dist in Makefile, then you will find 4 subdirectories under $ (APR) install, respectively, Bin, Lib, Include and build, where we are interested in only include and Lib. Here's an example of a Apr app, project.

The directory of the project is organized as follows:

$ (Apr_path)

-Dist

-Lib

-Include

-Examples

-Apr_app

-Make.properties

-Makefile

-APR_APP.C

The contents of our Make.properties file are as follows:

#

# The APR app demo

#

CC = Gcc-wall

BASEDIR =$ (Home)/apr-1.1.1/examples/apr_app

Aprdir =$ (Home)/apr-1.1.1

Aprver = 1

Aprincl =$ (Aprdir)/dist/include/apr-$ (aprver)

Aprlib =$ (Aprdir)/dist/lib

DEFS =-d_reentrant-d_posix_pthread_semantics-d_debug_

LIBS =-l$ (aprlib)-lapr-$ (aprver)/

-lpthread-lxnet-lposix4-ldl-lkstat-lnsl-lkvm-lz-lelf-lm-lsocket-ladm

incl =-i$ (APRINCL)

Cflags =$ (DEFS) $ (incl)

The contents of the makefile file are as follows:

Include Make.properties

TARGET = Apr_app

OBJS = APR_APP.O

All: $ (TARGET)

$ (TARGET): $ (OBJS)

$ (CC) ${cflags}-o $@$ (OBJS) ${libs}

Clean

Rm-f Core $ (TARGET) $ (OBJS)

The apr_app.c file uses the Proc_child.c file in the $ (apr_path)/test directory. Compile and run everything OK.

V. Go on

The process of analyzing APR is also the process of learning the UNIX advanced system mechanism, and I will continue APR analysis in time.

Apr Analysis-Design article as a portable run-time environment, Apr design is certainly very subtle, but there are some limitations to the user.

Apr comes with a brief design document with concise text, many of which are worthy of our reference, mainly from three aspects.

1, type

1 Apr provides and advises users to use APR custom data type. A lot of benefits, such as easy code porting, avoiding unnecessary type conversions between data (if you don't use APR's custom data type, you'll need to do some type conversion of the arguments when using some of the APR-provided interfaces) The name of the custom data type is more self-describing and improves the readability of the code. The basic custom data types offered by APR include:

typedef unsigned char apr_byte_t;

typedef short APR_INT16_T;

typedef unsigned short apr_uint16_t;

typedef int apr_int32_t;

typedef unsigned int apr_uint32_t;

typedef long Long apr_int64_t;

typedef unsigned long long apr_uint64_t;

These are all defined in Apr.h, and Apr.h are generated by the Configure Program on UNIX platforms, and the actual types of APR custom types on different platforms may be completely inconsistent.

2 It is also worth mentioning in the APR design document, it is called "DSO, MMAP, process, thread" and so on as "base types". It is difficult to understand in Chinese, it is estimated to refer to apr_mmap_t these types. Let's just understand, ^_^.

3 Another feature is that most APR types contain a apr_pool_t type field that allocates the memory used within the APR, and any APR function requires memory to be allocated through it. If you create a new type, you'd better add a apr_pool_t type of field to the type, otherwise all APR functions that manipulate that type require a apr_pool_t type parameter.

2. function

1 Understanding APR's function design is helpful for reading Apr code. If you look at the APR code, you'll find many function declarations similar to the Apr_declare (apr_hash_t *) Apr_hash_make (apr_pool_t*pool) with Apr_declare macros. Why add a Apr_declare? In Apr.h, there is an explanation for this: "The statement form of the common function of the fixed number parameter of APR