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 a variety of specific operating system platforms and invoke different processing functions for different platforms. With the further development of Apache, the Apache organization decided to separate and develop these universal functions into a new project. 　　In this way, the development of APR is isolated from Apache, and Apache uses only Apr. Currently APR is mostly used by Apache, but due to the good portability of APR, some C programs that need porting are also starting to use Apr. APR enables the processing of platform details to move down. For applications, they do not need to consider the specific platform, whether UNIX, Linux or window, the application execution of the interface is basically consistent. Therefore, for APR, portability and a unified upper-level interface are an important consideration. This was not the first goal of APR, but it was originally intended to merge all the code used in Apache into a common codebase, but this was not the right strategy, so the APR changed its target later. 　　Sometimes it is not a good thing to use public code, such as how to map a request to a thread or a process that is platform-dependent, so a common code base does not make this distinction. The goal of APR is to safely merge all the code that can be merged without sacrificing performance. One of the first goals of APR is to provide a common, unified Operation function interface for all platforms (not parts), which is a great goal, and certainly unrealistic. We can't support all the features of all platforms, so APR is currently available for all APR feature support for most platforms, including Win32, OS/2, BeOS, Darwin, Linux, and more. In order to achieve this goal, APR developers must create a series of feature macros (FEATURE MACROS) for those features that cannot be run on all platforms to differentiate between the various platforms. These feature macro definitions are very simple, usually as follows: Apr_has_feature If a platform has this feature, the macro must be set to true, such as Linux and Windows have a memory-mapped file, and APR provides the operating interface of the memory-mapped file. So on these two platforms, the APR_HAS_MMAP macro must be set, and 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 those who use unsupported functions in the program. Basic types of files supported in APRClip Name Description atomic/srclib/apr/atomic atomic operation DSO/SRCLIB/APR/DSO Dynamic load shared library fileio/srclib/apr/file_io file IO processing mmap/srclib/apr/m 　　Map memory Map file locks/srclib/apr/locks process and thread mutex memory/srclib/apr/memory memory pool operations network_io/srclib/apr/network_io Network IO Processing Poll/srclib/apr/poll poll io table/srclib/apr/tables apache Array (stack) and table as well as hash table Process/srclib/apr/threadproc process and thread operations user/ Srclib/apr/user User and User group operation Time/srclib/apr/time time operation String/srclib/apr/strings string operation PASSWORD/SRCLIB/APR/PASSWD terminal password Dealing with Misc/srclib/apr/misc, 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 this is an impulse to look at Apache's implementation because the underlying library used by the department has a "certain source" with Apache server. The end of the recent project, the wish will be realized.

One, what is Apr?

After so many years of development, Apache server encapsulates some common runtime interfaces for everyone, which is Apache portable run-time libraries, APR.

Ii. Directory organization of APR

After downloading apr-1.1.1.tar.gz from www.apache.org to local decompression, the directory structure of APR is very clear.

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

2) All the functions of the interface are placed in their own separate directory, such as ThreadProc, mmap and so on;

3) also is the relevant platform building tool files such as makefile.in. Once seen in the ACE code, all of the Ace's source files (. cpp) are placed in a directory and appear to be confusing. Apr gave me a good first impression.

4) Go to each function interface subdirectory, take ThreadProc as an example, there are 5 subdirectories under it, BeOS, NetWare, Os2, UNIX, and Win32, respectively. The name of APR is also understandable, and each subdirectory contains a unique implementation source file for each platform.

Third, Apr construction

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

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

In the $ (APR)/include directory, because APR considers portability, the most basic Apr.h file is generated automatically at build time, where apr.h.in resembles a template as an input source for apr.h generators. 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 $ (APR)/build under *.sh file access rights, should first chmod, otherwise make when the error will be prompted.

Iv. Application of APR

We first make an install, for example, we specify prefix=$ (Apr)/dist in makefile, then when you do install, you will find 4 subdirectories in the $ (APR)/dist, respectively, Bin, Lib, Include and build, where we are interested only in include and Lib. The following is an example of an Apr app project.

The catalogue 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 under the $ (apr_path)/test directory. Compile and run everything OK.

Five, GO on

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

Apr analysis-Design as a portable runtime environment, Apr design is of course very subtle, but there are some limitations to the user at the same time.

Apr comes with a short design document, text Concise, many of the design ideas are worthy of our reference, mainly from three aspects of the discussion.

1. Type

1) Apr provides and recommends users to use APR custom data types, many benefits, such as easy code porting, to avoid unnecessary type conversion between data (if you do not use the APR custom data type, you use some APR provided by the interface, you need to do some parameter type conversion) The name of the custom data type is more self-descriptive and improves the readability of the code. The basic custom data types provided 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 defined in Apr.h, and Apr.h is generated by the Configure program on the UNIX platform, and the actual type of APR custom type on different platforms is entirely possible inconsistent.

2) It is also worth mentioning that in the APR design document, it is called "DSO, MMAP, process, thread" and so on as "base types". Difficult to understand in Chinese, it is estimated that apr_mmap_t these types. Right vote so understanding, ^_^.

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

2. Functions

1) Understanding APR's function design is helpful for reading Apr code. Looking at the APR code you will find a lot of functions like Apr_declare (apr_hash_t *) Apr_hash_make (apr_pool_t*pool) with Apr_declare macros, what exactly does that mean? Why do you want to add a apr_declare? There is an explanation in Apr.h: "The Declaration form of the common function of the fixed number parameter of APR