From out in left field... this was sitting amidst my drafts. Dunno how
relevant it still is.
From: Aaron Bannert [EMAIL PROTECTED]
Sent: Tuesday, February 05, 2002 10:30 AM
On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote:
On OS/2 the only native mechanism that has
wrowe 02/02/11 16:07:34
Modified:file_io/win32 open.c
Log:
I don't trust that the OS is even returning an error - if the handle
is an invalid handle - I'm not certain that's an error. Certainly
this code is safer - merits pushing into .32
if (file_handle
+1, Agreed and backed out.
Mladen - would you substitute the misc/unix implementation and report back
with a patch to that file only, if a patch is required? Otherwise, just
the updated build files [zipped as you had them] would be great.
Bill
- Original Message -
From: Greg Stein
Ok... took us quite a bit of blood [mostly inflicted on one another],
sweat and tears but the bugs are gone again from the Win32 service.
The question is how can we tell?
Tell us!
Because WinNT's SCM (Service Control Manager) has very narrow constraints
on system startup timing, real
/win32/ perhaps ;)
Bill Stoddard wrote:
Cool. Definitely saving this away for use later.
Bill
From: William A. Rowe, Jr. [EMAIL PROTECTED]
Sent: Tuesday, February 12, 2002 10:51 PM
... Had to write up my own detailed flavor of an strace
/ApiSpy32 style utility, with enough feedback
From: Mladen Turk [EMAIL PROTECTED]
Sent: Saturday, February 16, 2002 7:09 AM
From: Bill Tutt [EMAIL PROTECTED]
Sent: Saturday, February 16, 2002 12:57 AM
Not quite. Yes we're calling kill, but you also don't want an A/V dialog
to pop up and prevent the process from exiting. The reason
From: Mladen Turk [EMAIL PROTECTED]
Sent: Saturday, February 16, 2002 12:26 PM
I'm sorry if my English Leeds to some misunderstanding.
So does mine, ask most English speakers :)
My primary intention
with that patch was to try to kill the entire process tree. I suppose that
everyone sees
From: [EMAIL PROTECTED]
Sent: Tuesday, February 19, 2002 2:51 PM
stoddard02/02/19 12:51:35
Modified:locks/win32 global_mutex.c
.CHANGES libapr.dsp apr.dsp
Log:
Implement apr_global_mutex_foo() on Windows. This is basically identical
to
From: Aaron Bannert [EMAIL PROTECTED]
Sent: Wednesday, February 20, 2002 4:13 PM
On Wed, Feb 20, 2002 at 02:27:37PM -0600, William Rowe wrote:
The more I consider the win32 fix, this netware and the coming BeOS fix, I
believe we need
two symbols;
APR_GLOBAL_MUTEX_IS_THREAD_MUTEX
From: Aaron Bannert [EMAIL PROTECTED]
Sent: Wednesday, February 20, 2002 6:32 PM
On Wed, Feb 20, 2002 at 06:23:05PM -0600, William Rowe wrote:
An alternative would be to #define APR_PROC_MUTEX_IS_GLOBAL
in the include/arch/foo/proc_mutex.h and let that dictate how
global_mutex.c is
From: Karl Fogel [EMAIL PROTECTED]
Sent: Wednesday, February 20, 2002 11:09 PM
Faller, Gyula [EMAIL PROTECTED] writes:
I downloaded subversion-r1302 tarball yesterday, tried to load the
subversion.dsw into VisualStudio 6.0 and tried to build it. But the VS
ceased to load the apr.dsp. It
From: Karl Fogel [EMAIL PROTECTED]
Sent: Thursday, February 21, 2002 1:45 AM
The problem is that we rolled a tarball that has the Unix
line-ending style everywhere. If someone checks out apr/ on Windows
using CVS (say), they would get the DOS-style endings...
Of course, you could throw up a
At 02:00 PM 2/28/2002, Greg Stein wrote:
On Thu, Feb 28, 2002 at 09:21:36AM -0800, Justin Erenkrantz wrote:
...
This shouldn't be too much of a problem because BDB will try to
hide that, but APR will *not* handle large files on Linux since
they disable sendfile() with 64bit files. Since APR is
At 04:14 AM 3/5/2002, you wrote:
To build APR is not that difficult. On the Windows platform you either
need MSVC or cygwin.
Please be advised;
the cygwin build is NOT a win32 platform build - it uses the cygwin emulation
layer, with all it's beauty and blemishes :)
We would -certainly-
At 12:05 PM 3/7/2002, you wrote:
On 7 Mar 2002, Jeff Trawick wrote:
| Any reason this didn't get committed?
If everyone likes this general framework, I can do research and get more
OSes that have largefile support added into that patch, besides just
having Solaris = 2.6 enabled.
Also, I know
Before anyone even _considers_ polluting the API [which would
raise an instant veto from me] we have to finally address the create
time issue on non-Unix. Then we can get such a patch committed
to fit this resolution of this issue..
Unix has ctime, mtime and atime. How often will we change all
At 02:29 PM 3/14/2002, I wrote:
Shall we add crtime to track the file creation timestamp, and mark ctime
as not present on all the non-unix platforms, while marking crtime as
invalid on win32?
s/win32/unix/. Unix is the one that doesn't support crtime. Most others
don't support ctime, IIUC.
At 01:38 PM 3/16/2002, you wrote:
There were some Unix specific threading code added to apr_initialize() at
some point, and WIN32 wasn't listed in the non-Unix OS's list. Shouldn't
there be a UNIX define somewhere that can be used instead? (If need be,
provided by a generic APR header; so as to
At 01:46 PM 3/16/2002, you wrote:
DOH, I see what happened. A new win32 specific version was added. I
forgot I was using VC++ 7 (which doesn't read the dsp files anymore), and
had imported the project file (which meant I didn't get the new updates).
Sorry about that... on a now related note:
At 11:20 AM 3/18/2002, you wrote:
Can we please change the name of APR_XtOffsetOf() [and APR_XtOffset]?
APR_OFFSETOF() or apr_offsetof() or something. Xt is the namespace of the
X11 toolkit--we don't need to perpetuate it in our version of the same
thing.
+1 (it's a macro, use caps :-) At first
At 01:56 PM 3/19/2002, you wrote:
any objections ?
if we do this we can move some other functions which are generic into
apr-util.
ap_escape_os_path for example
That example should move to apr (associated with apr_proc_create),
not apr-util. Other uses of gen_test_char should move to apr-util
? And as for not passing a structure (as was in
my original patch), why not? It doesn't seem to be much different than
defining apr_stat_t or some other apr_* structure abstraction.
Thanks.
Rob Simonson
[EMAIL PROTECTED]
- Forwarded by Robert Simonson/Rochester/IBM on 03/21/2002 12:15 PM
-
William A. Rowe
At 10:00 AM 3/22/2002, you wrote:
To: William A. Rowe, Jr. [EMAIL PROTECTED]
Cc: dev@apr.apache.org, Jeff Trawick [EMAIL PROTECTED]
I've taken a shot at redoing this. Is this more what you're thinking?
Thanks.
Rob Simonson
[EMAIL PROTECTED]
Terrific! I'll commit as soon as I have a free minute
At 08:13 PM 4/1/2002, Jeff Trawick wrote:
[EMAIL PROTECTED] writes:
jerenkrantz02/04/01 11:30:27
Modified:.CHANGES apr-config.in
Log:
Fix apr-config so that it will not attempt to cd to bindir if it doesn't
exist yet.
beauteous!!!
I take this as Justin's +1 ... but
Are these also for consideration in the 2.0.34 release?
Bill
gregames02/04/01 13:07:13
Modified:buildapr_hints.m4
.STATUS
Log:
FreeBSD: use fcntl cross-process locks by default. Make note of problems
experienced with flock and SysV sems.
Revision
Now tagged with APACHE_2_0_34
jerenkrantz02/04/01 11:30:27
Modified:.CHANGES apr-config.in
Log:
Fix apr-config so that it will not attempt to cd to bindir if it doesn't
exist yet.
Revision ChangesPath
1.250 +3 -0 apr/CHANGES
1.15 +5 -1
It would be, except that we won't handle more than ONE size_t's worth
of data at a time within a single bucket.
The patch to normalize to one size_t's worth of data took a 71 line delta.
The patch to normalize to any off_t's worth of data was at 500 lines and
growing when I gave up.
I've said it a
At 10:14 PM 4/1/2002, you wrote:
Humm... I would be suprised if
sendfile has a limit like this. If it does, then it is a
bug in the OS IMHO. In principle, sendfile should work on any file
supported by the OS...
Where do you see 64 bits of size here?
BOOL TransmitFile(
SOCKET
hSocket,
HANDLE
At 03:11 AM 4/13/2002, you wrote:
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]
Sent: 13 April 2002 08:52
Do we really have to have the UUID functions in APR? Could we move
them to apr-util?
+1 on moving it.
-1 on moving it, unless we are dumping the Win32 uuid.c source which
uses the OS
A suggestion to implement in apr_app_initialize, but first some background.
Without harming apr_initialize(), which should continue to be useful
for initializing apr in a non-apr application (e.g. a mod_jk connector built
with apr, that is written for Apache 1.3), I had started an
At 04:39 PM 4/14/2002, Sander Striker wrote:
From: Sascha Schumann [mailto:[EMAIL PROTECTED]
Sent: 14 April 2002 22:46
do {
fd = open(/dev/null, O_RDWR);
} while (fd 3);
close(fd);
And this is what most daemons (mostly) do. We could create a
convenience function for
At 10:27 AM 4/16/2002, Karl Fogel wrote:
Greg Stein [EMAIL PROTECTED] writes:
The Windows UUIDs are a helluva better than ours in terms of uniqueness. We
compensate, but Windows does a much better job.
Or if we find that really unclean, then abstract one key portion of
the uuid code and keep it
At 09:32 AM 4/16/2002, you wrote:
brane 02/04/16 07:32:03
Modified:include apr_errno.h
Log:
On Windows, ERROR_PATH_NOT_FOUND is an ENOENT, not an ENOTDIR -- same
as OS/2.
I'm somewhat dubious of this change. Can you please point to the use case
(a specific scenario) that this
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno what NetWare does here, anymore.
Two options; the
At 02:16 PM 4/17/2002, William A. Rowe, Jr. wrote:
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms. I dunno
At 10:29 PM 4/17/2002, you wrote:
William A. Rowe, Jr. wrote:
While we consider Stas' ideas for a portable tmpdir, we should also consider
breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths
as well.) These semantics change considerably from Win32 to unix and
other platforms
At 06:16 AM 4/19/2002, Jeff Trawick wrote:
Mladen Turk [EMAIL PROTECTED] writes:
Hi,
Dunno if I miss something, but the server/client test on WIN32 doesn't
work.
Well, as far I've been able to track the things down the non-blocking
sockets are the bugger.
It seems to me that server.c is a
The ctime field is interpreted differently, and misunderstood even by Unix
programmers, as Martin spelled out very nicely a while ago.
When a file is created [on unix or win32] the inode is instantiated. So ctime
and mtime are set to the 'creation time'.
When the file is modified, the mtime value
http://www.apacheweek.com/features/apachepda/
was an april fools joke. What isn't a joke is that Apache is based on APR,
the Apache Portability Runtime. That library isolates 90% of the pain of
porting Apache to another platform (currently many Unicies, Netware, OS2
and Windows 9x and NT
At 03:37 PM 5/10/2002, Aaron Bannert wrote:
OTOH, I don't think we should be encouraging non-zero checks on status
values.
if (my_apr_err != APR_SUCCESS) {
..uh-oh...
}
this one good. :)
Not really.
Consider that it encourages authors to use (my_app_err == APR_EAGAIN).
That is
At 05:07 PM 5/10/2002, Ryan Bloom wrote:
Symbol renames in APR are going to cause a problem for the web server.
Apache 2.0.36 is using the same major MMN as 2.0.35, but it isn't
compatible, because apr_explode_time was removed (as a single example,
there are more). We need to have some way to fix
Well, I'm ready to reverse my earlier position on uuid.
Here's the issue; we've recoded apr-iconv in terms of platform-neutral apr.
Ergo, we must bake apr before we are ready to put apr-iconv in the oven,
but that means we can't build apr_xlate_* into apr.
So, move apr_xlate_* into apr-util (along
At 03:40 PM 5/11/2002, Brian Pane wrote:
Sebastian Bergmann wrote:
[EMAIL PROTECTED]: Unresolved external symbol
I think this means that the new apr_strmatch.c source file
in apr-util needs to be listed in aprutil.dsp. Can someone
familiar with the win32 build setup please advise on the details
At 04:27 PM 5/12/2002, brane wrote:
William A. Rowe, Jr. wrote:
apr/i18n/unix/utf8_ucs2.c - apr/i18n/win32/utf8_ucs2.c [private]
apr/i18n/unix/xlate.c - apr-util/i18n/xlate.c
would this satisfy everyone?
+1, assuming utf8 - wchar_t conversion is still available on all platforms.
With a caviat
At 04:40 PM 5/15/2002, JF B wrote:
--- apr/locks/win32/thread_cond.c
Wed Mar 13 15:39:22 2002
+++ apr_new/locks/win32/thread_cond.c Wed May 8 18:25:52 2002
@@ -85,28 +85,33 @@
{
[...]
apr_thread_mutex_lock(mutex);
@@ -115,8 +120,52 @@
APR_DECLARE(apr_status_t)
At 10:27 AM 5/17/2002, you wrote:
Ben Laurie [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
trawick 02/05/17 07:58:27
Modified:strings apr_cpystrn.c
Log:
don't check for malloc() failure in our strdup() replacement
E - why not?
we're going to get segfaults
At 05:57 PM 5/20/2002, Greg Stein wrote:
On Fri, May 17, 2002 at 02:38:27PM -0500, William A. Rowe, Jr. wrote:
...
trawick 02/05/17 07:58:27
Modified:strings apr_cpystrn.c
Log:
don't check for malloc() failure in our strdup() replacement
...
We have an callback
Hardware? OS? Rev level?
At 09:47 PM 5/20/2002, you wrote:
My time test is failing. I get a mismatch:
checking localtime explode == GMT implode mismatch
apr_now()1021948993979908
apr_implode() returned 1021981393979908
At 09:51 PM 5/20/2002, Jon Travis wrote:
On Mon, May 20, 2002 at 07:47:24PM -0700, Jon Travis wrote:
My time test is failing. I get a mismatch:
checking localtime explode == GMT implode mismatch
apr_now()1021948993979908
At 08:05 PM 5/21/2002, you wrote:
On Tue, 21 May 2002, Greg Stein wrote:
Euh... we switched over to a shared library to specifically fix this
problem. Are you saying that that didn't work? I'm not buying it... :-)
sooo, i guess the answer to my question on how to disable expat is
you can't ?
i
At 11:01 PM 5/22/2002, Karsten Paige Huneycutt wrote:
According to the API posted in
Message-ID: [EMAIL PROTECTED]
(which is the last mention I can find in the dev@apr.apache.org archives),
the apr_spipe_t looks _great_ for parent-child IPC, but is in no way meant
to serve the same function that
Attached is a patch to introduce a new locking semantic to our thread_mutex.
Right now we presume the 'default' is unnested. Well, that saves 30% of the
processing time on Unix, but it would cripple Win32 (which gets a critical
section
in 10 instructions or so IF there is no contention... and
At 03:14 PM 5/29/2002, Sander wrote:
While we're at it, apr_allocator_alloc and apr_allocator_free are also
defined inline. I don't think that makes much sense, given the size of
those functions.
Hmm, so windows isn't smart enough to do both inlining and exporting?
I'd like the stuff inlined in
At 04:09 PM 5/29/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
Branko Čibej wrote:
Ho hum. I think there's also a bug in apr_pool_initialize. The sequence
there is
apr_allocator_create(global_allocator)
apr_pool_create_ex(global_pool, , global_allocator)
wrowe 2002/05/30 21:37:27
Modified:test aprtest.dsw
Added: test testapp.c testapp.dsp testappnt.dsp
Log:
Some win32 experimental code I'm playing with. Simply demonstrates
how to configure an app for WinNT or all Win32 applications. I expect
to extend
At 05:24 AM 6/2/2002, Chuck Murcko wrote:
Is this warning:
htpasswd.o: In function `main':
/x1/home/chuck/httpd-2.0-nightly/support/htpasswd.c(.text+0xa84): warning:
tmpnam() possibly used unsafely; consider using mkstemp()
1) the sort of thing to involve apr in, or
Yes... it has to be portable
That's a placeholder for an decision not made (I believe we apr_pcalloc,
so it isn't a huge issue between = 0 or omitting it entirely.)
However, if we really were strict, we should call apr_file_info_get()
on the new file entity and set the pipe value based on the file type, no?
At 01:51 PM
At 02:21 PM 6/3/2002, you wrote:
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
That's a placeholder for an decision not made (I believe we apr_pcalloc,
so it isn't a huge issue between = 0 or omitting it entirely.)
Oh right :) (To most people, it just looks like the same bug as with
the flags
I've noticed that we do very little to handle pipes correctly in
apr_os_file_put().
Would it make sense to introduce APR_FILE_PIPECHECK to ask
apr_os_file_put() to first check an apr_file_info_get() of the handle, and
set the flags correctly if this is a pipe device (e.g. pass this flag for
I just don't get this. It seems trivial.
Why aren't we porting apr_strftime, Mladen?
FWIW... I tossed my 15 minutes at this today and I have no extra time
remaining this week. I won't commit the file code till I have time to
thoroughly digest it, and deadlines loom. I'll try to commit it over
At 11:02 AM 6/5/2002, FirstBill wrote:
Also, I considered first using a flag in the apr_socket_t structure,
but my
problem is that there is already one: 'disconnected'. I would use this
flag, but after many review of the code, I still don't know the
utility of
this flag.
Has to do with
I just got bit by apr_parent_get_pool (bad, bad name).
So I've hacked up a example patch for apr_allocator_max_free_set.
First, adding -D APR_STRICT, coders can test that they don't use
deprecated symbols when building their code against apr headers.
Second, if the user defines APR_FAST_COMPAT,
At 04:11 PM 6/8/2002, Garrett wrote:
after the recent renaming of functions, i ran into a bunch of compile
errors. here are the changes i had to make to get things building
again.
Commited, thanks!
That looks like it aught to have been the twin to inherit_unset
(unset_inherit), no?
Committing the correct fix now, thanks for the catch Brian (will presume all
else was well when you built on unix.)
Bill
At 11:42 PM 6/8/2002, you wrote:
brianp 2002/06/08 21:42:59
Modified:include
At 04:08 AM 6/8/2002, Andi Gutmans wrote:
I just checked and it seems like Apache APR memory pools use mutex locking.
It'd be better to use functions like the Win32 ones which don't use mutex
locking (as we made sure that only one thread allocates from its pool).
This could be achieved by
At 05:04 PM 6/10/2002, you wrote:
I am tired of seeing this stupid change to the semantics of time_t
under Unix continue to cause bugs in every project that uses APR.
I must have missed that discussion traveling. Pointers please?
apr_time_t must be in seconds. If folks want APR to keep time in
At 09:15 PM 6/10/2002, you wrote:
William A. Rowe, Jr. wrote:
apr_time_t must be in seconds. If folks want APR to keep time in
microseconds, then they had bloody well change the type name
accordingly.
apr_time_t must nothing :-) Let's discuss *should(s)*
time_t is seconds. I love
At 09:31 PM 6/10/2002, I wrote:
usec * 1048575 / 100 = busec
bsec * 100 / 1048575 = usec
whoops, s/1048575/1048576/
At 10:14 PM 6/10/2002, Brian Pane
wrote:
William A. Rowe, Jr.
wrote:
At 09:31 PM 6/10/2002, I
wrote:
usec * 1048575 / 100 =
busec
bsec * 100 / 1048575 = usec
whoops, s/1048575/1048576/
That's a major improvement. I was going to complain about
the need for both a 64-bit multiplication
I'm trying to pre-simplify any future patch we might choose to apply for
time handling. Seems like we should clean house before trying any new
games with apr_time_t (including -renaming- apr_time_t and other symbols
that have confused porters.)
I notice especially that server-timeout seems to be
At 12:06 PM 6/12/2002, you wrote:
On 12 Jun 2002 [EMAIL PROTECTED] wrote:
+#define APR_TIME_USEC(time) ((apr_int32_t)(time) % APR_USEC_PER_SEC)
+
+#define APR_TIME_SEC(time) ((apr_int64_t)(time) / APR_USEC_PER_SEC)
+
+#define APR_TIME_FROM_SEC(sec) ((apr_time_t)(sec) *
At 09:20 AM 6/25/2002, Per Einar Ellefsen wrote:
Hi again Bill,
At 22:51 19.06.2002, William A. Rowe, Jr. wrote:
If we could set up an evening next week or over the weekend, perhaps we have
an informal Win32/mingw hackathon on irc://irc.openprojects.net/ #apr channel
to trade ideas with anyone
Well, I did it today. Plugged in libapr tagged APACHE_2_0_39 into an
APACHE_2_0_35 and APACHE_2_0_36 libaprutil + httpd. Of course
we changed the bucket semantics and behavior too much to actually bring
libaprutil up to the 2.0.39 rev. This was a plug-in, binary compatibility
experiment.
And
At 02:42 AM 6/27/2002, Sander Striker wrote:
The offending file is include/apr_allocator.h, a relative youngster,
introduced
on 15 march 2002.
I ment to back up and retitle the post ... thanks for pointing that out...
85 apr_memnode_t *next;
86 striker 1.6 apr_memnode_t
At 01:00 PM 6/27/2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Yep - with HP-UX running on 64-bit Itanium, and using the 64-bit data model.
The side effect of having the long val in the union definition is that
it'll have corrupted the mutex/semaphore while creating the proc_mutex
itself
ambiguity observation :-)
At 1:11 PM -0500 6/27/02, William A. Rowe, Jr. wrote:
At 01:00 PM 6/27/2002, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Yep - with HP-UX running on 64-bit Itanium, and using the 64-bit data
model.
The side effect of having the long val in the union definition is that
it'll
At 02:13 AM 6/28/2002, Cliff Woolley wrote:
[...]
First, why is apr_table_do APR_DECLARE_NONSTD()'d in the header file, but
APR_DECLARE()'d in the .c file? I'm guessing the _NONSTD() is the right
one, but I'm still a bit hazy on these things.
That is a bug, AFAICT. It should be picked up by
I have one bit that must be broken before 1.0, and cannot be remedied easily.
I'd like to simply break these things before Apache 2.0.40 is tagged.
apr_pstrcatv should have never been declared _NONSTD, it was and there
isn't much we can do about it without breaking binary compat or introducing
a
At 01:22 PM 6/28/2002, you wrote:
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
If Cliff wants to commit the semantic change to apr_table_[v]do, I'll
+1 here and raise you a _NONSTD correction. Along with Sander's
changes to make the unsafe transparent apr_allocator.h structure
opaque, I'd
If it is used by -anybody- they trust the existing implementation.
That said, it should behave sensibly. The fact that you've asked three
times says you want to change it.
Make it so ;-)
Bill
At 01:38 PM 6/28/2002, Cliff Woolley wrote:
On Fri, 28 Jun 2002, William A. Rowe, Jr. wrote:
IMHO
At 02:43 PM 6/28/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
Since we're talking about semantics, breakage, etc, I'll take the
opportunity to bore everybody with an issue I'd like resolved, too;
Namely, the semantics of the APR_STATUS_IS_* macros.
I've said several times before that
At 02:11 PM 6/28/2002, Brian Pane wrote:
I want to break something: binary compatibility for the pool API.
This has been on my list for a long time, but I haven't yet had
time to implement it.
What you are describing is [was] SMS.
Even with the opaque structure, we are still facing derefs that
At 10:23 AM 7/2/2002, Brian Pane wrote:
Do you get a correct tv_nsec if you remove the cast to 32-bit int
in the apr_time_usec macro?
Yes and no... it isn't the cast (usec or nsec, for that matter, fit in a
signed
32 bit integer.) It was the order of evaluation;
-#define apr_time_usec(time)
At 01:32 PM 7/2/2002, Cliff Woolley wrote:
On 2 Jul 2002 [EMAIL PROTECTED] wrote:
wrowe 2002/07/02 11:20:57
Modified:buckets apr_brigade.c
Log:
New emit on win32. Since this is a heap bucket, we are always dealing
in start offsets that fit in apr_size_t. This doesn't
At 02:48 PM 7/2/2002, Karl Fogel wrote:
Currently, apr_check_dir_empty() is living in the Subversion source
tree. The implementation looks portable, though; is there any reason
not to move this into APR?
One, the name sucks... perhaps apr_dir_is_empty()? Keep it named with the
other apr_dir_
At 05:25 PM 7/2/2002, wrote:
Modified:threadproc/win32 proc.c
Log:
Reverting the 1.76 and 1.77 changes, because they didn't work.
The child handles weren't properly inheritable, and redirected command
output got lost in the bit bucket.
On Which Flavor of Win32? Tests on XP and 2K
At 06:21 PM 7/2/2002, Brane wrote:
Incidentally, I'm beginning to suspect that the root cause of the problem
wasn't the patch itself, but the fact that apr_file_inherit_set is a noop.
Yup. That's brokenness.
BTW, why are the apr_*_inherit set functions declared void, not apr_status_t?
Good
At 06:55 PM 7/2/2002, Brane wrote:
William A. Rowe, Jr. wrote:
If there is a problem, it is NOT in this patch you reverted. It is probably
localized to apr_file_inherit_set(). That API didn't exist when the original
'make inheritable duplicates' was added.
The first order if business is to get
D:\clean\httpd-2.0\srclib\apr\file_io\win32\filedup.c(168) : error C2039:
'thlock' : is not a member of 'apr_file_t'
D:\clean\httpd-2.0\srclib\apr\file_io\win32\filedup.c(169) : error C2039:
'thlock' : is not a member of 'apr_file_t'
D:\clean\httpd-2.0\srclib\apr\file_io\win32\filedup.c(170) :
At 08:11 PM 7/2/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
William A. Rowe, Jr. wrote:
The correct fix was 10 minutes. A heads up to the list is ALWAYS warranted
unless vetoed code is checked into the repository.
Um. Sorry to disagree here, but the fix isn't entirely correct. You can't
use
At 07:56 AM 7/3/2002, [EMAIL PROTECTED] wrote:
Here's a patch for testproc.c that should tickle this particular problem. I
can't be 100% sure; I'm doing this at work, I only have an old version of APR,
and I can't update (getting timeouts).
As soon as I 'land' again I will give this the paces...
At 11:41 AM 7/8/2002, Aaron Bannert wrote:
On Mon, Jul 08, 2002 at 11:03:48AM
-0500, William A. Rowe, Jr. wrote:
At 12:02 PM 7/6/2002, Rasmus Lerdorf wrote:
What is a dynamic page if not a PHP page?
Like I said, Apache doesn't know if a file on disk is meant
for PHP or
not. The best way
At 11:46 AM 7/8/2002, Tony Finch wrote:
On Mon, Jul 08, 2002 at 01:20:24AM -0700, Aaron Bannert wrote:
I am strongly opposed to reusing the apr_time_t identifier.
I note that apr_time_t is a bad name in the first place, because POSIX
reserves all names ending in _t for the implementation. Feel
At 02:46 AM 7/8/2002, you wrote:
Based on the votes in STATUS, there's a consensus in favor of changing
from the current apr_time_t implementation to a binary microseconds
implementation. Meanwhile, I've removed most of the dependencies on
the old design from the httpd-2.0 code.
The next step
At 11:47 AM 7/7/2002, Aaron Bannert wrote:
On Sat, Jul 06, 2002 at 12:11:59PM -0700, Ryan Bloom wrote:
I vote to fix the API so that these kinds of mistakes can't happen in
the future.
+1, let's fix the API now. (I also strongly dislike input/output parameters.)
Microsoft's Win32 API was built
If autoconf fails to pick up memchr or strncasecmp, we build those fn's
into libapr.
Unfortunately, if using a dynamic clib, and later upgrading the clib or
moving those binaries on another machine with memchr or strncasecmp
in the clib, you will blow up from multiple symbols when loading the app.
At 01:14 PM 7/9/2002, you wrote:
Bill Stoddard wrote:
Where and when was the post that described this proposal? I'd like to take
a look. Is there a patch?
There's no patch that I know of, but here's the thread with wrowe's
original proposal for the binary microseconds design:
At 01:39 PM 7/10/2002, you wrote:
wrowe 2002/07/10 11:39:54
Modified:.renames_pending
Log:
Reorder alpha, and clarify apr_group_id_/apr_user_id_ [still some
discussion on those.]
+apr_group_id_get from apr_get_groupid
+apr_group_id_compare
At 01:25 AM 7/11/2002, Ryan Bloom wrote:
Well, you beat me by about five minutes. I just finished compiling
almost the exact same code.
Thanks for doing to work, your implementation is cleaner than mine was.
Speaking of which, are these the results you were looking for?
APR Poll Test
At 10:41 AM 7/11/2002, Brian Pane wrote:
On Thu, 2002-07-11 at 06:58, Bill Stoddard wrote:
I ran a quick profile with this patch and it eliminated a couple of
divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your
mileage may vary) which was good for 493 instructions. Still
301 - 400 of 3066 matches
Mail list logo
