Branko Äibej wrote:
>I've been trying to use the APR condition variables on Win32, and the
>dam' things kept deadlocking on me whatever I did. So, out of sheer
>desperation, I took a look at the implementation... well, let's say that
>I was awed by the number of bugs and race conditions I found in
I've been trying to use the APR condition variables on Win32, and the
dam' things kept deadlocking on me whatever I did. So, out of sheer
desperation, I took a look at the implementation... well, let's say that
I was awed by the number of bugs and race conditions I found in there. :-)
Anyway: I we
Justin Erenkrantz wrote:
> * random number generation API
uh-oh!
... but yes, it is approaching the top of my list!
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robe
At 03:27 AM 6/25/2003, Marc M. Adkins wrote:
>> * emulating the daemon/services foo within the Win32 port... but call it
>> a 'nice to have' ... I will try to dedicate cycles to this over
>> the summer.
>> It's not exactly a showstopper.
>
>Can you expand on this? Are you talking about the usu
At 10:01 AM 6/25/2003, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>>
>>Let me add
>>* no support of out-of-band network data whatsoever. That really concerns
>> me and I will probably address it over the next two weeks.
>
>Elaborate please.
send() takes a fourth argument, such as OOB. Ou
Justin Erenkrantz wrote:
--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley
<[EMAIL PROTECTED]> wrote:
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0 for almost a
year
now...
Off the top of my head I would
William A. Rowe, Jr. wrote:
At 01:04 AM 6/25/2003, Justin Erenkrantz wrote:
--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley <[EMAIL PROTECTED]>
wrote:
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0
Thanks for the answer.
So let me ask something else: How does people usually write
applications
using APR that can execute operations like die() (when something goes wrong)
but need to keep the allocate memory amount under control? I mean, our server
need to perform allocations
> There is a possibility of the APR team add a function like
>
> /** Free the given pointer. */
> APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
>
> to the current pool system? AFAIK it is only possible to
> deallocate memory
> deallocating the whole pool.
>
> I missing
> * emulating the daemon/services foo within the Win32 port... but call it
> a 'nice to have' ... I will try to dedicate cycles to this over
> the summer.
> It's not exactly a showstopper.
Can you expand on this? Are you talking about the usual "Windows doesn't
fork" problem, emulating Window
The pool design currently can't support this. It's optimized
for allocation speed; in the common case, apr_palloc requires
only a pointer addition. The downside of this design is that
there's no way to reclaim memory within a pool.
There's been talk in the past of trying a more general-purpose
al
Cliff Woolley wrote:
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
now...
We still have the 64-bit divisions in the apr_time_t code.
Brian
At 01:04 AM 6/25/2003, Justin Erenkrantz wrote:
>--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley <[EMAIL PROTECTED]>
>wrote:
>
>>What are the real issues stopping us from releasing APR 1.0? (Yes, I've
>>read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
>>now...
>
> >> why initialize separator only
> >>to overwrite it? I.e., why not:
> >>char separator[2];
> >>const char *delim1;
> >>const char *delim2;
> >>
> >>seperator[0] = (flags & APR_FILEPATH_NATIVE) ? '\\' : '/';
> >>separator[1] = 0;
> >>
> >>
> >
> >I copied the method used for
Hi,
There is a possibility of the APR team add a function like
/** Free the given pointer. */
APR_DECLARE(void *) apr_pfree(apr_pool_t *pool, void *pointer)
to the current pool system? AFAIK it is only possible to deallocate memory
deallocating the whole pool.
I missin
Saxon Druce wrote:
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: "APR dev"
Sent: Wednesday, June 25, 2003 2:42 PM
Subject: Re: [PATCH] filepath.c with Borland C++ Builder
why initialize separator only
to overwrite it? I.e., why not:
char separator[2];
const char *
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: "APR dev"
Sent: Wednesday, June 25, 2003 2:42 PM
Subject: Re: [PATCH] filepath.c with Borland C++ Builder
> Saxon Druce wrote:
>
> >--- apr/file_io/win32/filepath.c.oldTue May 13 14:35:32 2003
> >+++ apr/file_io/win32/fi
Saxon Druce wrote:
--- apr/file_io/win32/filepath.c.oldTue May 13 14:35:32 2003
+++ apr/file_io/win32/filepath.cTue May 13 14:38:31 2003
@@ -156,9 +156,11 @@
#else /* ndef(NETWARE) */
-char seperator[2] = { (flags & APR_FILEPATH_NATIVE) ? '\\' : '/', 0};
+char seperator[2] = {0,
Hi,
This is a repost of the patch below, which I posted on the 3rd of June and
14th of May.
Under Borland C++ Builder 6.0 (bcc32 5.6) the existing code produces about a
hundred warnings like this:
[C++ Warning] signal.h(65): W8017 Redefinition of 'SIGUSR1' is not identical
[C++ Warning] signal.h
Hi,
This is a repost of the patch below, which I posted on the 3rd of June and
13th of May, and actually first posted back in March 2002.
Under Borland C++ Builder 6.0 (bcc32 5.6) the existing code produces an
error, because the compiler can't handle the initializer. The patch makes it
possible t
> So, no real reason other than no one has time... -- justin
Tell me about it. Grad school didn't used to be this busy... but they
sure are keeping me on my toes this year! Sheesh! :)
--On Wednesday, June 25, 2003 1:29 AM -0400 Cliff Woolley
<[EMAIL PROTECTED]> wrote:
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
now...
Off the top of my head I would suggest:
* tmpfile handling
What are the real issues stopping us from releasing APR 1.0? (Yes, I've
read the STATUS file.) We've been "pushing toward" 1.0 for almost a year
now...
--Cliff
Title: Your information is not complete
Sign Up | Log In | Help
Title: Your information is not complete
Sign Up | Log In | Help
25 matches
Mail list logo
