forked from apache/apr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
STATUS
427 lines (353 loc) · 20.5 KB
/
STATUS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2002/06/28 23:15:19 $]
Release:
0.9.0-dev : in progress
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2.0a5 : released August 4, 2000
2.0a4 : released June 7, 2000
2.0a3 : released April 28, 2000
2.0a2 : released March 31, 2000
2.0a1 : released March 10, 2000
RELEASE SHOWSTOPPERS:
* Must namespace protect all include/apr_foo.h headers. Jon Travis
has especially observed these including apr and Apache-1.3.
Message-ID: <[email protected]>
(Those problems have been fixed, but it is a good example of
what to look for.)
Some headers with issues:
apr_fnmatch.h (FNM_foo)
apr_general.h (MAXIMUM_WAIT_OBJECTS)
apr_md5.h (MD5_DIGESTSIZE)
apr_network_io.h (MAX_SECONDS_TO_LINGER)
apr.hnw (READDIR_IS_THREAD_SAFE, ENUM_BITFIELD,
_POSIX_THREAD_SAFE_FUNCTIONS (?),
nuint8, nuint16, NGetLo8, NGetHi8,
HIBYTE, LOBYTE)
apr.hw (NO_USE_SIGACTION)
* complete the efforts started by DougM for cleaner fn naming
conventions: see proposed name changes in renames_pending
and offer up any additions/vetos/clarifications.
DougM offered to complete the work with his nifty perl rename
script at the hackathon.
* When Win32 apr_proc_create was fixed, the apr_proc_t hproc
member was added for that platform. That's a problem (and
was when pid was abused as well) since nobody goes and cleans
up hproc after the process is dead. Can't do a pool cleanup,
since apr_proc_create didn't allocate the apr_proc_t storage.
(Aren't transparent types swell?) Suggestions?
* Almost every API in APR depends on pools, but pool semantics
aren't a good match for a lot of applications. We need to find
a way to support alternate allocators polymorphically without
a significant performance penalty.
* extract the MAJOR version from apr_version.h and pass it to
libtool for use in applying version numbers to the shared
libraries.
CURRENT VOTES:
* apr_time_t has proven to be a performance problem in some key
apps (like httpd-2.0) due to the need for 64-bit division to
retrieve the seconds "field." Alternatives that have been
discussed on dev@apr are:
1) Keep the 64-bit int, but change it to use binary microseconds
(renaming the function to get rid of apr_time_t vs time_t confusion,
and having macros to convert BUSEC to USEC and back if need be)
+1: BrianP, Cliff, Brane, rbb, Jim, Thom
2) Add a separate data type (and supporting functions) for seconds only
-0: Cliff, Brane, rbb, Jim
3) Replace it with a struct with separate fields for sec and usec
-0: BrianP, Cliff, Brane, rbb, Thom
* For the atomics code to be efficient it depends on instructions
in newer sparc models. Unfortunately this means that binaries
optimized at build-time for these architectures will not work
on older hardware, regardless of the version of Solaris running.
The same is likely happening on the various x86 implementations.
Although I had high hopes for the atomics code, I think we can
not support it in a way that is compatible with the portability
goals of APR, and I hereby propose that we remove it from APR.
+1: Aaron
-0: Justin (I think it's warranted and fits with our portability
goals, but I'm not going to spend my time supporting it -
although I have spent more time on this than I'd like.
If someone wants to maintain it, more power to them. If
no one maintains it, this gets changed to a +1.),
BrianP,cliff,gregames:
(All the reasons why we don't want the processor-specific
code in APR are also reasons why I don't want to push
that code up into the apps that use APR. I'd rather
spend some more time searching for a workable solution
before we give up on atomics. Perhaps we should let
apps using the atomic API set a preprocessor flag to
choose an "optimal" or "portable" version of the atomic
ops?)
Sander (The positive sides of the atomics outweigh the negative
in my opinion. That said, I am not going to be the
one spending time on this, since asm on various
processors isn't really my game)
Jim,rbb:
(who thinks we'll need to reformat this vote) Any time
you make use of processor specific code for optimizations
or capability, you run into portability concerns. The
real option is to make atomics a compile-time option.
YES means you use the atomics code, based on the *build*
machine (and therefore carries some dependencies) or
NO which maintains "universal" portabiity, which is
what we have (but the default being NO atomics)
-1: IanH, BillS:
I don't agree. I think APR is the perfect place this kind of thing.
For platforms that support it is a big win, for ones which don't
they are no worse off than the alternative.
I can't maintain every asm implementation, but I am volunteering
for sparc/x86. (we could also grab the FreeBSD
implementations for HW they support)
Unfortunatly I was out of action for a month when half the
hubub was going on.
The other alternative for non-native support is maybe to turn
it into a spin lock
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* The return type of a thread function (void *) is inconsistent with
the type used in apr_thread_exit()/apr_thread_join() (apr_status_t).
The thread function's return type should be changed to apr_status_t
so that a return from the thread main function has the same effect
as apr_thread_exit().
See Message-Id: <[email protected]> for thread
discussing this.
+1: BrianH, Aaron
* Need some architecture/OS specific versions of the atomic operations.
progress: generic, solaris Sparc, FreeBSD5, linux, and OS/390 done
need: AIX, AS400, HPUX
* The new lock API is a full replacement for the old API, but is
not yet complete on all platforms. Components that are incomplete
or missing include:
Netware: apr_proc_mutex_*() (Is proc_mutex unnecessary on Netware?)
OS/2: apr_thread_cond_*(), apr_proc_mutex_*()
Less critical components that we may wish to add at some point:
Beos: apr_thread_rwlock_try*lock()
apr_proc_mutex_trylock()
Unix: apr_thread_rwlock_*() for platforms w/o rwlocks in pthread
Win32: apr_thread_rwlock_try*lock(), apr_thread_cond_timedwait(),
apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?)
* Need to contemplate apr_strftime... platforms vary. OtherBill
suggested this solution (but has no time to implement):
Document our list of 'supported' escapes.
Run some autoconf/m4 magic against the complete list we support.
Move the strftime re-implementation from time/win32 to time/unix.
Add some APR_HAVE_STRFTIME magic to use the system fn, or fail
over to time/unix/strftime.c.
Message-ID: <025e01c1a891$bf41f660$94c0b0d0@v505>
* Using reentrant libraries with non-threaded APR
- Anecdotal evidence exists that suggests it is bad to
mix reentrant and non-reentrant libraries and therefore
we should always use the reentrant versions.
- Unfortunately, on some platforms (AIX 4.2.1) defining
the reentrant flag (-D_THREAD_SAFE) causes builds to fail,
and so one would expect --disable-threads to fix this.
Although this has been fixed for that particular version
of AIX, it may be useful to only enable the reentrant
versions when threads are enabled.
How will we deal with this issue once APR becomes a standalone
library? It is perfectly legitimate to have apps needing
both versions (threaded/reentrant and non-threaded/non-reentrant)
on the same machine.
* Pools debugging
- Find a way to do check if a pool is used in multiple
threads, while the creation flags say it isn't. IOW,
when the pool was created with APR_POOL_FNEWALLOCATOR,
but without APR_POOL_FLOCK.
Currently, no matter what the creation flags say, we always
create a lock. Without it integrity_check() and
apr_pool_num_bytes() blow up (because they traverse pools
child lists that possibly belong to another thread, in
combination with the pool having no lock). However,
this might actually hide problems like creating a child pool
of a pool belonging to another thread.
Maybe a debug function apr_pool_set_owner(apr_thread_t *) in
combination with extra checks in integrity_check() will point
out these problems. apr_pool_set_owner() would need to be called
everytime the owner(the thread the pool is being used in) of
the pool changes.
- Implement apr_pool_join and apr_pool_lock. Those functions
are noops at the moment.
- Add stats to the pools code. We already have basic stats
in debug mode. Stats that tell us about wasted memory
in the production code require more thought.
Status: Sander Striker is looking into this (low priority)
* Deal with largefiles properly on those platforms that support it.
Justin says: Linux refuses to have sendfile support and largefiles
at the same time. Largefile autoconf patch:
http://www.apache.org/~jerenkrantz/apr_largefile.m4
* Get OTHER_CHILD support into Win32
Status: Bill S. is looking into this
* Win32 apr_proc_create fails to create 16 bit apps detached
(a win32 bug.) The question - test in advance (slow) or
recover gracefully from failure and try again? Only the test
method will work on Win9x, since it will appear to work, only
to encounter mangled pipes. Win2K (NT?) simply fails.
* SysV semaphore support isn't usable by Apache when started as
root because we don't have a way to allow the semaphore to be
used by the configured User and Group. Current work-around:
change the initial permissions to 0666. Needed code: See
1.3's http_main.c, SysV sem flavor of accept_mutex_init().
Status: Jim will look into this
Update: Apache deals with this itself, though it might be nice
if APR could do something.
* Build scripts do not recognise AIX 4.2.1 pthreads
Justin says: "Is this still true?"
* FirstBill says we need a new procattr, APR_CREATE_SUSPENDED (or
something similar) to direct ap_create_process to create the
process suspended. We also need a call to wake up the suspended
process. This may not be able to be implemented everywhere though.
Status: OtherBill asks, why? What is the benefit, how is it
portably implemented? Unless this creates some tangible that
mirrors another platform, then I'm -1.
* Replace tables with a proper opaque ADT that has pluggable
implementations (including something like the existing data type,
plus hash tables for speed, with options for more later).
Status: fanf is working on this.
* add a version number to apr_initialize() as an extra failsafe against
(APR) library version skew.
MsgID: <[email protected]>
Status: Greg +1 (volunteers), Jeff +1, Ryan +1, Tony -0(?), david +1
* add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
crypt() function is available, and a way to call it (whether it is
located in libc, libcrypt, or libufc)
Justin says: Should apr_crypt() be in apr-util?
Status: Greg +1 (volunteers)
* configure.in does post-processing on the AC_OUTPUT files (for
VPATH support). This means that config.status doesn't do the
right thing when you re-run it. We ought to revamp the makefiles
to do the right AC_SUBST stuff rather than depend upon rewriting.
Sascha: As the rewriter is a crude hack, I would not worry too
much about it. It is designed to go away once we have
a proper build system in place.
One of the perceived deficiencies of automake is that it
uses AC_SUBST too often, thereby slowing down the task of
generating Makefiles significantly, because it applies
dozens of substitutions to each Makefile. And why? Make's
built-in macro processing is much more powerful, and
combined with the include facility, generating Makefiles
becomes simpler and faster.
Justin says: "I think this got fixed with Roy's build changes."
* use os_(un)cork in network_io/unix/sendrecv.c for FreeBSD's
sendfile implementation.
david: The socket options stuff is now in and using it should
reduce the number of syscalls that are required for
os_cork and uncork, so the code should be reviewed to
make use of the new calls. If no-one beats me to it I'll
get around to it soonish...
* toss the per-Makefile setup of INCLUDES; shift to rules.mk.in
rbb: This is a bad thing IMHO. If we do this, then we
can't use these makefiles for anything else. For example,
apr-util
* add the rest of the pool accessor declare/impl macros.
Justin says: Both thread and file have the accessors now. Any others?
Status: Greg volunteers
* I think apr_open_stderr() and friends dup() the descriptor. That
would allow the new/returned file to be closed (via pool cleanup
or manually) without accidentally closing stderr/out.
Justin says: Is this "I think it should?"
* need to export the shared library extension (e.g. ".so") for the
platform. clients need to use this to construct filenames to
pass to apr_dso_load()
-- note on Win32 we distinguish 'apache module' names from other
'loadable module' names, so be careful with Apache's directive.
* Possible gmtime_r replacement in explode_time
On Solaris (and possibly others), the gmtime_r libc function obtains
a mutex. We have seen 21/25 threads being blocked in this mutex on
a threaded httpd MPM when requesting static pages. It may be worth
it to hand optimize this since there is no real need for a mutex at
the system level (straight arithmetic from what I can tell). If you
have access to the Solaris source code:
osnet_volume/usr/src/lib/libc/port/gen/time_comm.c.
* Add a way to query APR for what features it has at runtime (i.e.
threads).
Justin says: I'm not completely sold on this, but it has been mentioned
before and at least added to STATUS.
* apr_xlate.h generates a bunch of compiler warnings.
Jeff asks: which platform?
Justin says: Solaris with Forte 6.1.
* fcntl() oddness on Solaris. Under high loads, fcntl() decides to
return error code 46 (ENOLCK).
httpd (prefork MPM) error log says (predictably):
(46)No record locks available: couldn't grab the accept mutex
All of the children report this and subsequently exits. httpd is now
hosed. AFAICT, this does not look to be an out-of-fds error.
Solaris's man page says:
ENOLCK
The cmd argument is F_SETLK, F_SETLK64, F_SETLKW, or
F_SETLKW64 and satisfying the lock or unlock request
would result in the number of locked regions in the
system exceeding a system-imposed limit.
Justin says: What is this system-imposed limit and how do we change it?
This gives me more rationale for switching the default
interprocess lock mechanism to pthread (if available).
* Generate a good bug report to send to the FreeBSD hackers that details
the problems we have seen with threads and system calls (specifically
sendfile data is corrupted). From our analysis so far, we don't think
that this is an APR issue, but rather a FreeBSD kernel issue. Our
current solution is to just disable threads across the board on
FreeBSD.
MsgID: <[email protected]>
Status: Fixed in -CURRENT. MFC in about a week. Continuing
testing with threads on FreeBSD.
FreeBSD PR kern/32684:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/32684
* There are some optimizations that can be done to the new
apr_proc_*() functions (on UNIX). One that may reduce pointer
indirection would be to make the apr_proc_mutex_unix_lock_methods_t
first-class members of the apr_proc_mutex_t structure.
* Condition variables are tricky enough to use, and even trickier
to implement properly. We could really use a better test case
for those subtle quirks that sometimes creep into CV implementations.
* Once we are fully satisfied with the new lock API, we can
begin to migrate the old API to be implemented on top of the
new one, or just decide to get rid of it altogether.
* FreeBSD returns 45 (EOPNOTSUPP) when the lockfile is on a NFS
partition when you call fcntl(F_SETLKW). It may be good if we
can somehow detect this and error out when creating the lock
rather than waiting for the error to occur when acquiring lock.
* Fix autoconf tests for strerror_r on BeOS and remove the hack in
misc/unix/errorcodes.c to get error reporting working. Committed as
the solution is elusive at present.
* implement APR_PROGRAM_ENV and APR_PROGRAM_PATH on BeOS, OS/2,
Netware, and Win32.
* stat() on a few platforms (notably Solaris and AIX) succeeds for
a non-directory even if a trailing '/' was specified in the
name. APR should perhaps simulate the normal -1/ENOTDIR
behavior in APR routines which retrieve information about the
file. Note: Win2K fails GetFileAttributesEx in this scenario.
See OtherBill's comments in this message to [email protected]:
Message-Id: <5.1.0.14.2.20020315080852.00bce168@localhost>
Documentation that needs writing:
* API documentation
Ian Says: APR Stuff in now in Doxygen format, which is the first step.
* apr-site needs to be revamped with Anakia/XHTML.
Stuff waiting for code thawing after Beta 1:
* Identify and implement those protection bits that have general
usefulness, perhaps hidden, generic read-only [immutable],
effective current user permissions, etc.
* Maybe make the following functions return void instead of
apr_status_t, as they cannot ever error:
apr_md5_init()
apr_md5_update()
apr_md5_final()
apr_md5_encode()
apr_md5() /* plus make the obvious code tweak in this one */
(Volunteer: Karl Fogel <[email protected]>.)
However, don't do this until after apr and apr-util offer
library version numbers, and httpd uses those numbers to
indicate which version it needs. Until the libraries are
versioned, this api change is [somewhat] painful for httpd.
Status: Still in discussion, current leanings appear to be
Bill Stoddard -0.5 (?)
Sander Striker +1
Greg Stein +1
Karl Fogel +1
(Not sure if the negatives would stay negative given that the
change would now wait for the library versioning thing described
above, though.)
Justin says: If you do this, please move it into apr-util where md5
belongs! You'll have to address the random issue in
misc/unix/getuuid.c that forces md5 to be in APR.
Sander: +1 for the move.