gt; be pinged as a matter of courtesy?
>
> Or is his name there a mere technicality, perhaps a legacy
> of an initial code drop into svn?
>
> --
> Nick Kew
>
> --
Ryan Bloom
rbl...@gmail.com
On Fri, Jan 23, 2009 at 10:07 AM, William A. Rowe, Jr.
wrote:
> Ryan Bloom wrote:
> > Why do you want to jettison "edge platforms"? The original goal was to
> > keep HTTPd as portable as 1.3 was, which meant APR had to support
> > mainframes, OS/2, etc. All of tho
from HTTPd (the natural result of
dropping support from APR) seems like a decision that can only be made after
discussion with APR's users, not the developers of APR itself.
Just a few thoughts from the gallery.
Ryan
Ryan Bloom
r...@apache.org
r...@rkbloom.net
rbl...@gmail.com
On Fri, Jan
On Fri, Jun 13, 2008 at 3:15 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> Topic for a fun conversation: Should we detab the various
> APR source? We've never really instituted a specific coding
> style, ala httpd, but 1.3.x might not be a bad place to start.
> I'm proposing this for post-1.3.1 re
Ryan
On Fri, Jun 6, 2008 at 12:16 PM, Sander Striker <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 6, 2008 at 5:10 PM, Yann <[EMAIL PROTECTED]> wrote:
>> Christopher Key wrote:
>
> [...]
>> Ryan Bloom wrote:
>>> If this is what you really want/need, then I would
On Fri, Jun 6, 2008 at 9:18 AM, Yann <[EMAIL PROTECTED]> wrote:
> Erik Huelsmann wrote:
>>
>> On 6/6/08, Ryan Bloom <[EMAIL PROTECTED]> wrote:
>>>
>>> I don't think that there is any reason to not have a sizeof()
>>> function, other than
tages of opaque types, but is there a way an
>>>> apr_pool_sizeof() function be added (and exported) in the APR, simply
>>>> like :
>>>>
>>>> APR_DECLARE(apr_size_t) apr_pool_sizeof(void)
>>>> {
>>>> /* maybe the aligned SIZE
ring, instead of
> returning a malloc'ed copy of the static string so that when the caller
> calls free it will always work.
>
> Regards,
> Graham
> --
>
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
7;which' to do more, such as tell me where the heck
some specific lib or include lives on an INCLUDE or LIB path list. So
my solution is at http://people.apache.org/~wrowe/witch.c - and I'm
considering different possible homes for it - either here at the ASF, or
elsewhere if there really
, but would stink when it comes to using other
SSL implementations.
I see every modern crypto provider supporting the API David's proposed, and
the SHA/MD5 hashing I'm about to propose. The more 'special features' of one
provider we define, the more code we will have to write when
You could on Unix, but on Windows there is no fork command. It is
done with CreateProc (or something like that), which doesn't have
flexibility that fork has.
Ryan
On 4/11/06, Garrett Rooney <[EMAIL PROTECTED]> wrote:
> On 4/11/06, Ryan Bloom <[EMAIL PROTECTED]> wrote:
>
e's an easy way to get at the appropriate socket to call them
> from your module. It might need to be done inside the httpd core. On
> the other hand, I could be wrong, I'm just theorizing at this point.
>
> -garrett
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
e, so those fixes will go in
> with 0.9.11 and we'll call it a day. Another couple weeks and we can push
> all these changes to readwrite etc into a release, maybe get some folks
> to try out snapshots if it causes them grief.
>
> Bill
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Ok, it is committed to APR's README file now, with just a few changes.
I took your name out of the patch, because it is in the commit
message.
Ryan
On 10/15/05, Ryan Bloom <[EMAIL PROTECTED]> wrote:
> This is still in my inbox. I am in the middle of a big release at
> work, bu
* Maxime Petazzoni <[EMAIL PROTECTED]> [2005-09-19 09:02:10]:
>
> > * Ryan Bloom <[EMAIL PROTECTED]> [2005-09-18 19:42:53]:
> >
> > > If you don't mind, I'd like to include this with the ABTS package.
> > > I'll apply this patch over the
(GNU/Linux)
>
> iD8DBQFDLfNF7KsOe4Pmrg0RAnMAAKDHay9V+rfWvDj/oQgBp+ZDGoEl/wCfVNyg
> M24dLnpGVpVv10iQbL/9zFI=
> =icGO
> -END PGP SIGNATURE-
>
>
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
hinking of is having the bucket maintain its own state, and then
> reinsert _itself_ (as opposed to a new bucket) until the data is finished.
> Should that work, or is it asking for trouble?
>
> --
> Nick Kew
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
>
> What would be required to at least support safe loading of
> multiple modules with APR statically bundled.
> I presume the 'local' would be a way to go as default as Bill proposed.
>
>
> Regards,
> Mladen
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
s if there is a possibility to create a .so that
> will use APR as static library?
>
> Also what will happen if I have a multiple .so's inside the
> same process each with APR statically linked.
>
> Is something like that possible?
>
> Regards,
> Mladen.
>
--
Rya
and added to the hash list if the key isn't found.
>
> -Original Message-
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]
> Sent: den 7 augusti 2005 20:33
> To: Ante
> Cc: dev@apr.apache.org
> Subject: Re: Hash table problems
>
> You haven't really
0x08068023 in child_main (child_num_arg=0) at prefork.c:610
>
> #13 0x080680fa in make_child (s=0x80a9ea0, slot=0) at prefork.c:650
>
> #14 0x08068222 in startup_children (number_to_start=10) at prefork.c:722
>
> #15 0x0806862b in ap_mpm_run (_pconf=0x80a80f0, plog=0x80d2198, s=0x80a9ea0)
>
> at prefork.c:941
>
> #16 0x0806f239 in main (argc=2, argv=0xbb24) at main.c:618
>
>
>
> Any suggestions how I should fix this?
>
>
>
> //Andreas
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
ache.org/viewcvs.cgi/apr/apr/trunk/test/
>
> vh
>
> Mads Toftum
> --
> `Darn it, who spiked my coffee with water?!' - lwall
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
On Thu, 31 Mar 2005 15:37:21 +0200, Sander Striker <[EMAIL PROTECTED]> wrote:
> Ryan Bloom wrote:
> > If the documentation says what is
> > macro, then that is almost guaranteed to be out of date at some point
> > in the future. And, what happens when sometimes it is a
> [1] This is true for HEAD, apr-0.9.x and apr-1.x
>
> --
> Uwe Zeisberger
>
> http://www.google.com/search?q=i+squared
>
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
seems that waiting on pipe is not implemented for windows.
>
> Any suggestions?
>
> Thanks,
> -cktan
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
00, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> --On Friday, March 18, 2005 11:27 AM -0500 Ryan Bloom <[EMAIL PROTECTED]>
> wrote:
>
> > That's fine. Pay attention to what I suggested. Default to
> > non-native sendfile, until we have know that it works.
0, Justin Erenkrantz
<[EMAIL PROTECTED]> wrote:
> --On Friday, March 18, 2005 11:12 AM -0500 Ryan Bloom <[EMAIL PROTECTED]>
> wrote:
>
> > funny, I took the list of exceptions to be so large and hard to
> > maintain that it made more sense to go with Jeff's origin
some
> future releases? You could do lots of things to corrupt your kernel by tuning
> in other ways - so unless this is by default, I can't see why we should block
> this.
>
> > ...snip, snip...
>
> +1 to this list of exceptions and adding a new flag called APR_
other application ends up
jumping through hoops to use pools. Pools have their uses, but they
aren't meant to be used by every application, and I really wish I had
listened to the other developers who said I was making a mistake. Oh
well, live and learn.
Ryan
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
t;The biggest reasons to use APR, is pool method of memory management,
> >
> >
> As a matter of fact, pools can be a huge PITA, as we've found to our
> detriment in Subversion.
>
> -- Brane
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
utilized and still be within the spirit
> > of being commercial-friendly I think will limit the reach
> > and potential audience of dbd.
> >
> > I think it's worth our effort and time to look into what can be
> > done/negotiated with MySQL.
> >
>
> Agreed.
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
gr, should have sent this to the list.
Ryan
-- Forwarded message --
From: Ryan Bloom <[EMAIL PROTECTED]>
Date: Wed, 19 Jan 2005 15:05:10 -0500
Subject: Re: Re-architecture for 2.0 tree
To: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
So, I took
uctures.
Thoughts, comments, critisms, questions?
Ryan
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
. Any takers? I am only looking for one or two
people.
Ryan
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
he C standard but are checking for particular styles of C
> usage that we choose to uphold in order to better avoid bugs.
>
> I happen to advocate such practices to a greater extent than it seems you
> would
> choose to. We have to work to a common consensus of style within a giv
spective.
>
> Threads and the proposed threading patch I grok (and accept :),
> while condition variables I'm less familiar with. Perhaps Bannert,
> Bloom and some other condition variable gurus will pipe up.
>
> Bill
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
ed version compatibility,
> publishing a defined set of rules, it would be a very great shame for 1.0.0
> to actively hinder packagers from handling correct versioning of APR.
>
> So, please, review!
>
> Max.
>
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
macro there are cases when it's more than just (s) ==
> > APR_SUCCESS.
>
> just another note, I grep'd the code for "rc == APR_SUCCESS" and it looks
> like not even APR is using the macro everywhere...
>
> --Geoff
>
--
Ryan Bloom
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
in
and it works. We should collapse the build system to have just a
single way to build the tests on Windows.
Ryan
On Fri, 2 Jul 2004 11:14:06 -0400 , Ed Holyat <[EMAIL PROTECTED]> wrote:
>
> How Do I build it on Windows?
>
>
> -Original Message-
> From: Ryan Bloo
testall.c was replaced when the testsuite moved to abts. ABTS does the
same thing as testall, only much cleaner.
Ryan
On Fri, 2 Jul 2004, Ed Holyat wrote:
> I am trying to build testall.dsw on Windows XP. testall.dsw fails to buil=
d
> because testall.obj isn't available.
>
> Is the test suite
s so that we know the resoluts from our
MD5 algorithm are portable to other platforms.
Ryan
_______
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
oc/realloc, and
tried convert it quickly.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
ion of the configure scripts.
> >
> > That precludes any 'oh, hey, look they are here' magic. They really
> > do have to be in the local repository or hardcoded paths. -- justin
> >
>
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
On Thu, 29 Aug 2002, Aaron Bannert wrote:
> On Thu, Aug 29, 2002 at 02:24:28PM -0400, Ryan Bloom wrote:
> > > +1 from me, I prefer APR actually.
> >
> > I am really uncomfortable with this going under the APR project. As
> > things stand right now, it just doesn&
... getting this UI over gnophone.com/
> so does it still make sense
> to use APR as the portability of the core then yet another portability layer
> for
> the GUI say like wxWindows or is there a better strategy ..
>
>
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
ed upon. If we want to change that fine, but let's have
that discussion please. Right now, people are changing the mission
without ever discussing it on-list.
Ryan
_______
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
ine our scope. I see that as
> focusing on "portable" libraries.
Which, from the votes above, I would consider to be a change from
your previous position. Which is fine, but you don't get to decide on the
mission statement for the whole project.
Ryan
_
On Tue, 27 Aug 2002, Aaron Bannert wrote:
> On Tue, Aug 27, 2002 at 02:15:43PM -0400, Ryan Bloom wrote:
> > > Just to clarify, by "we" I meant the voting majority of the APR PMC
> > > (aparently only with the approval of the board), not the whims of
> > > t
On Tue, 27 Aug 2002, Aaron Bannert wrote:
> On Tue, Aug 27, 2002 at 01:56:39PM -0400, Ryan Bloom wrote:
> > > APR is whatever we want it to be...
> >
> > APR is NOT what we make it. The APR project has a VERY well defined
> > mission and goal. Take a look at the
start
> thinking about our projects in terms of functionality rather than
> language or protocol.
But the "functionality" for APR is a portable run-time, not every library
that we can think to write.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
ssion was decided upon at the start of the
project, and it was approved by the board. Changing that mission requires
acceptance by the entire PMC, and the board must approve it.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
re
about to release 1.0, and we have stated that the API will not change
during major releases.
Hope all of this helps you make your decision.
Ryan
_______
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
owever the problem is that if the ASF
> doesn't accept it, then it is unlikely that it will be under an ASF
> style license. So it's kinda a chicken & egg problemo.. :-(
>
> -- Jon
>
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
> + vbuff.curpos = buf;
> +vbuff.endpos = buf + len - 1;
> +}
> cc = apr_vformatter(snprintf_flush, &vbuff, format, ap);
> if (len != 0) {
> *vbuff.curpos = '\0';
>
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
On Sun, 25 Aug 2002, Ben Laurie wrote:
> Ryan Bloom wrote:
> > On Fri, 23 Aug 2002, Jim Jagielski wrote:
> >
> >
> >>We are already not compliant, since we overload %p.
> >>
> >>Not sure if I understand #1: If len is 0, we return 0 and don'
g 8554, and it has a fix. Problem 1 is not in any bug DB, but
> > I have a fix already.
> >
> > My question, is whether we really want to fix these problems, because we
> > don't _have_ to be POSIX compliant. My own opinion is that they should be
> > fixed.
>
>
> Which I believe means I don't have commit access. Could I be added to the
> APR project, or should I just submit my patch?
>
> Thanks,
>
>
--
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
Okay, I had the time to update the site.
Ryan
On Mon, 19 Aug 2002, Ryan Bloom wrote:
>
> I'll try to do this today. Fair warning, I just started a new job, so my
> time will be sparse for a few days.
>
> Ryan
>
> On Mon, 19 Aug 2002, B. W. Fitzpatrick wrote
mission.
> > Sorry for the bogus report.
> >
> > I'm using IE 5.1.4 for Mac OS X. The page source contains:
>
> I've just verified this and checked in the fix.
>
> Ryan, can you update the live site?
>
> -Fitz
>
--
__
ache httpd-2.0 should be listed too. :-)
>
> (<http://apr.apache.org/> says "If you are using APR, and would like
> your project recognized, please send e-mail to the developer's
> mailing list.")
>
> -David Mankin
>
--
_____
On Thu, 15 Aug 2002, [ISO-8859-1] Wilfredo Sánchez wrote:
>I'm going to go ahead and rename the function, so the API is correct.
>
>How do I test for the size of a type with autoconf?
I believe that Will Rowe already changed the function name. Also, you
don't need to check the size, we
Take a look at apr/misc/unix/version.c.
Ryan
On Tue, 13 Aug 2002, Ryan Bloom wrote:
> On Tue, 13 Aug 2002, Aaron Bannert wrote:
>
> > On Tue, Aug 13, 2002 at 03:10:14PM -0400, Jim Jagielski wrote:
> > > Uh oh. Looks like we'll be hashing this out again :)
> >
; (I'd like to make a release once we get the versioning into code, but
> you already knew that. :)
Dude, settled how? We have run-time versioning, Greg committed it a
long time ago, and it is being used by APR and Subversion.
Ryan
_____
On Tue, 13 Aug 2002, Jim Jagielski wrote:
> Ryan Bloom wrote:
> >
> > Ok. I don't honestly think we will get a release out the door this week
> > anyway, but I also don't believe that Will has done a lot with the
> > licensing stuff. Most of that was Greg S
On Tue, 13 Aug 2002, Jim Jagielski wrote:
> Ryan Bloom wrote:
> >
> > Why are we waiting for Bill to come back? I thought the whole point of
> > OSS was that no one person was so important that we couldn't continue
> > without them?
> >
>
> I'm
g further mastication :-)
That is in Apache, which has nothing to do with APR. The proposal
specifically states that APR will stop dealing with microseconds, which
makes it useless for an app outside of httpd that wants microsecond
resolution.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
no one person was so important that we couldn't continue
without them?
Ryan
_______
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
dy agreed on how to
fix it, or even that there was a real problem.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> At 05:05 PM 8/4/2002, Aaron Bannert wrote:
> >On Sun, Aug 04, 2002 at 06:29:34PM -, [EMAIL PROTECTED] wrote:
> > > wrowe 2002/08/04 11:29:33
> > >
> > > Modified:include apr_time.h
> > >time/unix time.c
> >
> If you're polling on a single file/socket descriptor,
> both APIs do about the same processing on the first poll
> (mostly just copying from the apr_pollfd_t to the OS's
> pollfd struct). If you expect to have to call poll on
> that same descriptor repeatedly, the apr_pollset API
> is more effic
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> At 01:59 PM 8/2/2002, Ryan Bloom wrote:
> > > Modified:poll/unix poll.c
> > > Log:
> > > We safely ignore palloc failures [we can segv in the
allocator].
> > > We cannot ignor
Where can I get access to a machine that is displaying this behavior?
Ryan
--
Ryan Bloom
[EMAIL PROTECTED] [EMAIL PROTECTED]
> -Original Message-
> From: David Reid [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 02, 2002
> Modified:poll/unix poll.c
> Log:
> We safely ignore palloc failures [we can segv in the allocator].
> We cannot ignore alloca/malloc failures.
We generally ignore memory allocation errors of all kinds in the server
and APR. The general thought has always been that if you are act
> > > Even if we don't build it, this is extremely good practice that
the
> folks
> > > rolling and releasing the tarball TAG the apr-iconv tree in sync
with
> > > the current apr and apr-util trees..
> >
> >I completely disagree. The problem is that the httpd_roll_release
> >script is for rollin
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> At 11:42 AM 8/1/2002, you wrote:
> >ianh2002/08/01 09:42:33
> >
> > Modified:buildhttpd_roll_release
> > Log:
> > we need apr-iconv now
>
> Even if we don't build it, this is extremely good practice that the
folks
>
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
>
> "Ryan Bloom" <[EMAIL PROTECTED]> wrote:
>
> > I have no problem implementing this feature, but do it right (which
may
> > mean not using apr_socket_t), so that it is portable. We have
enough
> > pe
> > While the code is small, to the best of my knowledge, it is also not
> > portable. If it is portable, +1. If it is Unix only, -1.
>
> Well, it is not a "globally portable" feature... As fork(), for
instance,
> which doesn't exist on Windows, but still APR supports it.
Okay, I can accept tha
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> "Ryan Bloom" <[EMAIL PROTECTED]> writes:
>
> > > I suspect that rebuilding the native pollset (e.g., struct pollfd
> > > array) every time apr_poll() is called is harmful to Apache.
>
> > > > I am biting my tongue here, but Jeff, you are the person who
> > > > specifically stated that the heavy-duty API was too slow for us
to
> > use.
> > >
> > > I said it was too slow and/or cumbersome to use in a particular
> > > situation that does not correspond to something an APR app woul
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> "Ryan Bloom" <[EMAIL PROTECTED]> writes:
>
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > >
> > > Brian Pane <[EMAIL PROTECTED]> writes:
> > >
> &
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > To continue the recent discussions on the problems in the current
> > apr_poll API, here's a patch for apr_poll.h that illustrates my
> > proposed fix.
> >
> > What I'm proposing here is to split
ut it back.
I'm going away for a few more days. I was a lot happier when I wasn't
reading this e-mail list.
Ryan
------
Ryan Bloom
[EMAIL PROTECTED] [EMAIL PROTECTED]
> -Original Message-
> From: Brian Pane [mailto:[EMAIL
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> "Ryan Bloom" <[EMAIL PROTECTED]> writes:
>
> > No, the old design was completely bogus. As proof, Trawick vetoed
even
> > using the damned thing inside of APR.
>
> I listed two conditions
> >>new implementation results in an O(n) time wrapper (due to the need
to
> >>copy n pollfd objects on every poll call), not to mention the memory
> >>
> >>
> >leak.
> >
> >
> >>>BTW, that interface was removed because it was too bulky and
complex
> >>>
> >>>
> >and
> >
> >
> >>>too slow.
> >>>
>
> Ryan Bloom wrote:
>
> >Congratulations. You have just designed the interface that was
removed
> >two weeks ago. :-(
> >
>
> Exactly. The old API had the right design: an abstract poll object
with
> accessor functions, so that the poll wrapper can run in O(
> I run an old linux box in my basement that firewalls the ADSL & runs
the
> house network & has an apache for some very low volume family domains.
> I got a ton of virtual hosts set up and the apache that came with the
> SuSe of late 2000 was getting weird and messing up the vhosts and
> probably
Congratulations. You have just designed the interface that was removed
two weeks ago. :-(
BTW, that interface was removed because it was too bulky and complex and
too slow.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St
Okay, so this is essentially exactly what we had before I re-wrote
apr_poll() a few weeks ago. There are some differences, such as keeping
the allocated structure, but at the end of the day any implementation
based on this design will have the same problem that the previous design
had, namely per
> From: Karl Fogel [mailto:[EMAIL PROTECTED]
>
> Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> > In APR calls, if EINVAL is produced, it should use APR_EINVAL.
> >
> > And, for checking for error, the caller should use
> > APR_STATUS_IS_EINVAL(s). -- justin
>
> Well, this is *us* generating t
s*. His comments are about
> resulting code size and performance. I think Ulrich hasn't been clear in
> that regard, but you (Jim) are also (seemingly) tending to be a bit
> obstinate in wanting to do it your way :-)
Yeah, I definately didn't understand Ulrich's concerns until he
specifically stated what he was trying to solve.
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
We should fix this, without a doubt. Please file a bug in the bug
system at http://nagoya.apache.org so that this can be tracked.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> From: Ryan Bloom [mailto:[EMAIL PROTECTED]
>
> > From: Ulrich Drepper [mailto:[EMAIL PROTECTED]
> >
> > On Tue, 2002-07-16 at 17:49, Blair Zajac wrote:
> >
> > > We don't need to make a copy of errno.
> >
> > Oh yes, we do. When it comes
> From: Ulrich Drepper [mailto:[EMAIL PROTECTED]
>
> On Tue, 2002-07-16 at 17:49, Blair Zajac wrote:
>
> > We don't need to make a copy of errno.
>
> Oh yes, we do. When it comes to interaction with the C library you
can
> believe me. errno is no simple variable on almost all systems. So,
use
I'll say it again. Leave apr_time_t alone. If a program wants 1 second
resolution, then they should be using time_t. apr_time_t specifically
provides microsecond resolution.
Different solutions for different problems. :-)
Ryan
--
Ryan
++1!
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message-
> From: David Reid [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 15, 2002 4:36 PM
>
> On Mon, 15 Jul 2002, Cliff Woolley wrote:
>
> > realsecs = 22/21 * (realusecs >> 20) + 22/21;
> > realsecs = 44/21 * (realusecs >> 20);
>
> I'm obviously on crack. :)
>
> That last line is of course totally wrong and shouldn't have been
there.
> :)
Ok, cool. I thought I had forgotten someth
to this. Don't
> know what it is just now though...
I keep thinking that we know what the accuracy difference is, and we know
how many seconds we have, so a simple 32-bit multiplication should be able
to solve this problem. hmm...
Ryan
___
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
---
Feel free to 'cvs rm' it. If it is only there for reference, people can
get to it from the Attic.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Ori
That version isn't used anymore, and it should be removed. I believe
wrowe left it in the directory for reference purposes, and was going to
remove it in time.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [
++1 here.
Ryan
--
Ryan Bloom [EMAIL PROTECTED]
645 Howard St. [EMAIL PROTECTED]
San Francisco, CA
> -Original Message-
> From: David Reid [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 15, 2002 8:00 AM
1 - 100 of 446 matches
Mail list logo
