apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <mma...@Doorways.org>
Subject RE: [STATUS] (apr) Wed Jun 25 23:45:21 EDT 2003
Date Thu, 26 Jun 2003 16:52:01 GMT
>       Win32: apr_thread_rwlock_try*lock(), apr_thread_cond_timedwait(),
>              apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?)

apr_thread_rwlock_try*lock() may now work on Win32.  I (more or less) copied
the code from the OS/2 version.  I didn't test it other than to run the
existing test suite on it.  If the existing test suite is sufficient, it
works, otherwise it needs verification.

>     * I think apr_open_stderr() and friends *should* dup() the
>       descriptor.  That would allow the new/returned file to be closed
>       (via pool cleanup or manually) without accidentally closing
>       stderr/out.

Hey, I noticed (crashed doing) that!  I thought it was just supposed to work
that way.  Now that you mention it, using dup() in this matter would be
better.

> Documentation that needs writing:
>
>     * API documentation

The apr_vformatter documentation doesn't seem to have all of its escape
characters documented, only the %pp variation from the norm.  I had to look
in the code for the 'q' length specification.  Moreover, the documentation
that _is_ there is hard to read.

> Stuff for post 1.0:

I would suggest:

	* Routines for acquiring basic information about running processes
	  such as memory usage, CPU usage, etc.  Should work for processes
	  that were _not_ started via apr_proc_create().  Should allow
	  enumeration of all processes on system (subject to user permissions).

But that's just me, and probably no one else cares. ;)

mma


Mime
View raw message