Anyone have objections to moving the apr_pools.c file into the
memory/unix directory?
This will mean that all the memory code is in one place and we don't
build anything in the lib directory anymore so it can be removed from
our build in configure.in. It also allows us to do the sms ==
On Wed, 4 Jul 2001, Justin Erenkrantz wrote:
On Wed, Jul 04, 2001 at 09:35:05PM +0100, David Reid wrote:
Anyone have objections to moving the apr_pools.c file into the
memory/unix directory?
No objections here, but I wouldn't worry about the history.
Just note that the file originally
On Wed, Jul 04, 2001 at 04:08:45PM -0700, [EMAIL PROTECTED] wrote:
For moves like this, we usually try to keep the history. That is the way
the group has always done it in the past. This has caused arguments
before, but I would prefer to keep the history.
Oh, I wasn't aware of that policy.
OK..
got a strange question...
I'm looking at the shared memory functions (in unix), and am struggling
to find out how one can attach to
a shared memory segment already created by another process.
I want to be able to create a a shared memory version of the hash table
which will be accessable
On Wed, 4 Jul 2001, Ian Holsman wrote:
OK..
got a strange question...
I'm looking at the shared memory functions (in unix), and am struggling
to find out how one can attach to
a shared memory segment already created by another process.
I want to be able to create a a shared memory version
On Wed, Jul 04, 2001 at 04:41:02PM -0700, [EMAIL PROTECTED] wrote:
Currently you can't, because MM doesn't really support it. We need to
re-write the shared memory code, but it doesn't make a lot of sense to do
that until the SMS stuff calms down.
Yeah, I was going to say about that same
On Thu, Jul 05, 2001 at 12:02:10AM -, [EMAIL PROTECTED] wrote:
trawick 01/07/04 17:02:10
Modified:.configure.in
buildapr_common.m4
Log:
Stop trying to provide cross-process pthread mutexes on systems where
the form of shared memory used with
On Wed, 4 Jul 2001 [EMAIL PROTECTED] wrote:
+1 for moving it. To move it without losing history, log on to deadalus,
and do the following:
+1 for moving it. Definitely keep the history. It's much easier than
trying to compare across files. And that's always been the group's
consensus after
On 5 Jul 2001 [EMAIL PROTECTED] wrote:
We need to ALWAYS do the seek if we are reading from the file. This is
unfortunate from a performance perspective, but right now, I can have an
offset of 0 in the bucket, but be referring to a file that has been read
from. If we don't seek
We need to ALWAYS do the seek if we are reading from the file. This is
unfortunate from a performance perspective, but right now, I can have an
offset of 0 in the bucket, but be referring to a file that has been read
from. If we don't seek before reading from the bucket, we get
SMS uses it
The Win32 .DSP files are also missing 2 SMS's sms_block sms_trivial,
but my DSP's are different at the
moment, so I can't submit the patch for those .
..Ian
--
cvs server: Diffing .
Index: thread.c
===
RCS file:
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/06/29 08:00:48 $]
Release:
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
APRUTIL LIBRARY STATUS: -*-text-*-
Last modified at [$Date: 2001/06/27 21:07:15 $]
Release:
2.0a9 : released December 12, 2000
RELEASE SHOWSTOPPERS:
* Need apu_compat.h to track the latest renames
Status: someone want to step up to diff
This implements a hash table using shared memory.
Limitations:
* doesn't have a freelist, so deletes aren't reclaimed
* and can't expand it's size (dont know how to implement this with
current shared memory system)
* no locking (yet)
It is intended for use in modules having a large
(me dumb when no reply-to header)
Justin Erenkrantz at [EMAIL PROTECTED] wrote:
[ Moving to [EMAIL PROTECTED] ]
From where ? :)
On Wed, Jul 04, 2001 at 05:48:42PM -0700, [EMAIL PROTECTED] wrote:
APR doesn't install the library correctly yet. Until we fix that, we need
to use disable
For information's sake, the big problem is MM. I can generate at install
libapr's shared libraries, but since we don't install MM, we have big
problems. It's on my short list now. :-)
Ryan
On Thu, 5 Jul 2001, Pier P. Fumagalli wrote:
(me dumb when no reply-to header)
Justin Erenkrantz at
On Wed, Jul 04, 2001 at 09:01:35PM -0700, Ian Holsman wrote:
This implements a hash table using shared memory.
Limitations:
* doesn't have a freelist, so deletes aren't reclaimed
* and can't expand it's size (dont know how to implement this with
current shared memory system)
*
I dislike this. This duplicates a lot of logic that we already have in
regular hash files. The whole point of the SMS logic is to make this sort
of thing not necessary anymore. With SMS, we just pass a shared pool into
the apr_make_hash function, and we get a hash table in shared memory.
I
Pier P. Fumagalli wrote:
(me dumb when no reply-to header)
Justin Erenkrantz at [EMAIL PROTECTED] wrote:
[ Moving to [EMAIL PROTECTED] ]
From where ? :)
On Wed, Jul 04, 2001 at 05:48:42PM -0700, [EMAIL PROTECTED] wrote:
APR doesn't install the library correctly yet. Until we
hiya david,
i just want to double-check something. i got caught out by
creating cookies of 1 year which actually turned into 30 seconds
because apr_time_t is in microseconds :) :)
so, could you confirm at the points below for me? thanks
also, i should point out some experience from seeing
Copying the Tomcat list (barf barf, too much crossposting :) :)
Pier
jean-frederic clere at [EMAIL PROTECTED] wrote:
I'm going to do it... And if he remembers his -1, he'll roll back :)
Well, I said that the problems we had in mod_webapp due to APR should be
solved in APR not in
On Mon, Jul 02, 2001 at 07:10:27PM +0200, Sander Striker wrote:
On Mon, Jul 02, 2001 at 09:38:37AM -0700, Ian Holsman wrote:
Just wondering if any has got one of these going,
how does the proposed SMS shared library handle pointers?
Can you please expand a bit further on what you
Pier P. Fumagalli wrote:
Copying the Tomcat list (barf barf, too much crossposting :) :)
Pier
jean-frederic clere at [EMAIL PROTECTED] wrote:
I'm going to do it... And if he remembers his -1, he'll roll back :)
Well, I said that the problems we had in mod_webapp due to
hiya,
didn't get a response back regarding the namedpipes / ntpipes
issues, still have some questions outstanding, perhaps someone
can help me understand?
i asked earlier about whether it is possible to do a select()
on a [unix] namedpipe: i have since discovered apr_poll()
so the question
This implements a hash table using shared memory.
Limitations:
* doesn't have a freelist, so deletes aren't reclaimed
* and can't expand it's size (dont know how to implement this with
current shared
memory system)
To the best of my knowledge, you cannot expand a shared memory
I am teetering on a -1 for this patch. You are hacking around a more
fundamental problem.
If we cannot fix problems like this w/o impacting the performance of all
applications that
need to read files, then APR is seriously broken.
Bill
- Original Message -
From: [EMAIL PROTECTED]
To:
I am also worried with mod_webapp for Apache-2.0, what will happend when a
internal typedef of APR comming from httpd will be used by mod_webapp and will
be handled differently there because of different APR version?
This is going to be handled by having APR provide a programatic way of
I am also worried with mod_webapp for Apache-2.0, what will happend when a
internal typedef of APR comming from httpd will be used by mod_webapp and
will
be handled differently there because of different APR version?
Who said that for Apache 2.0 there will be 2 different versions
On Thu, 5 Jul 2001, Bill Stoddard wrote:
I am teetering on a -1 for this patch. You are hacking around a more
fundamental problem. If we cannot fix problems like this w/o impacting
the performance of all applications that need to read files, then APR
is seriously broken.
Well, that's
On Thu, 5 Jul 2001, Bill Stoddard wrote:
I am teetering on a -1 for this patch. You are hacking around a more
fundamental problem. If we cannot fix problems like this w/o impacting
the performance of all applications that need to read files, then APR
is seriously broken.
Well, that's
PS: The common case for this segment of code is that the offset will be
non-zero, since it reads in from a file in 8KB hunks, incrementing the
offset each time. So removing the conditional actually (very slightly)
improves the performance of this section for the common case. Only the
case
On Thu, 5 Jul 2001, Bill Stoddard wrote:
If you perform a read on a file and don't specifiy an offset, then you
should assume you will be reading from the current file pointer
maintained by the system (or by apr_file_t in the XTHREAD case). If
you have an apr_file_t open and you are reading
On Thu, 5 Jul 2001, Bill Stoddard wrote:
Maybe there is something very fundamental that I a missing here.
Each 8K chunk that is read causes the system to increment its file
pointer for that open fd. You should not need to call seek() to do
something the system is already doing for you under
What specific problem are we trying to fix? I agree for the need for a seek()
in the
case you are describing below but it seems to be an unusual case, at least for
the
webserver. We need to focus on making APR work efficiently for the most common
cases and
resist the urge to create an
On Thu, 5 Jul 2001, Bill Stoddard wrote:
You can't guarantee that consecutive reads from file buckets read from the
next spot in the file. In fact, they very frequently jump around.
Give me a common example of reads from file buckets jumping around.
The chunk filter. Or any filter for
I am teetering on a -1 for this patch. You are hacking around a more
fundamental
problem.
If we cannot fix problems like this w/o impacting the performance of all
applications
that
need to read files, then APR is seriously broken.
Huh? If I have a file that I put into a
On Thu, 5 Jul 2001, Cliff Woolley wrote:
The chunk filter.
s/chunk/byterange/
Duh.
--Cliff
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
On Thu, 5 Jul 2001, Bill Stoddard wrote:
What specific problem are we trying to fix? I agree for the need for a
seek() in the
case you are describing below but it seems to be an unusual case, at least
for the
webserver. We need to focus on making APR work efficiently for the most
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote:
Perhaps just having a different offset, like -1 to specify that you should
always use the OS's file offset.
Hmm... that *only* works if you can guarantee that no other code (eg, some
filter) is going muck with the brigade. IMO you're much better off
Perhaps just having a different offset, like -1 to specify that you should
always use the OS's file offset.
Hmm... that *only* works if you can guarantee that no other code (eg, some
filter) is going muck with the brigade. IMO you're much better off
keeping track of the offset than
On 04 Jul 2001 21:16:56 -0700, Justin Erenkrantz wrote:
On Wed, Jul 04, 2001 at 09:01:35PM -0700, Ian Holsman wrote:
This implements a hash table using shared memory.
Limitations:
* doesn't have a freelist, so deletes aren't reclaimed
* and can't expand it's size (dont know how to
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote:
I agree, but Bill is saying that in http, we can usually count on the OS
file offset being correct, so he wants a performance enhancement for that
case. I have no problem adding an enhancement for that special case,
assuming it is called out as a
On 5 Jul 2001, Ian Holsman wrote:
On 04 Jul 2001 21:16:56 -0700, Justin Erenkrantz wrote:
On Wed, Jul 04, 2001 at 09:01:35PM -0700, Ian Holsman wrote:
This implements a hash table using shared memory.
Limitations:
* doesn't have a freelist, so deletes aren't reclaimed
* and
oops...forgot the list.
On 05 Jul 2001 09:14:03 -0700, Ian Holsman wrote:
On 05 Jul 2001 08:46:05 -0700, [EMAIL PROTECTED] wrote:
On 5 Jul 2001, Ian Holsman wrote:
On 04 Jul 2001 21:16:56 -0700, Justin Erenkrantz wrote:
On Wed, Jul 04, 2001 at 09:01:35PM -0700, Ian Holsman wrote:
On 05 Jul 2001 09:14:03 -0700, Ian Holsman wrote:
On 05 Jul 2001 08:46:05 -0700, [EMAIL PROTECTED] wrote:
On 5 Jul 2001, Ian Holsman wrote:
On 04 Jul 2001 21:16:56 -0700, Justin Erenkrantz wrote:
On Wed, Jul 04, 2001 at 09:01:35PM -0700, Ian Holsman wrote:
This implements
On Thu, Jul 05, 2001 at 08:36:24AM -0700, Ian Holsman wrote:
In the conversations I have seen SMS was always talked about post 2.0
Release.
Is this still the case?
Nah. I think SMS is getting very close to being ready for more people
to play with. In order to solve some problems, we're
hiya david,
i just want to double-check something. i got caught out by
creating cookies of 1 year which actually turned into 30 seconds
because apr_time_t is in microseconds :) :)
so, could you confirm at the points below for me? thanks
also, i should point out some experience from
On 05 Jul 2001 22:59:25 +0100, David Reid wrote:
OK, to comment on this prior to the patch being posted...
I have SMS running as pools and the implementation I have manages to run the
server at 80% of the speed of pools. This is with no changes to the httpd
code except using --enable-sms on
48 matches
Mail list logo
