On Fri, Aug 03, 2001 at 09:35:02AM -0400, Dale Ghent wrote:
> On Fri, 3 Aug 2001, Aaron Bannert wrote:
>
> | The usage of a thread-level yield is really orthogonal to the
> | performance characteristics of the OS scheduler, even on two-level
> | systems like Solaris. In all cases (one-level or two
On Fri, 3 Aug 2001, Aaron Bannert wrote:
| The usage of a thread-level yield is really orthogonal to the
| performance characteristics of the OS scheduler, even on two-level
| systems like Solaris. In all cases (one-level or two-level), thread
| libraries will at some point have to multiplex one k
On Thu, Aug 02, 2001 at 08:25:33PM -0700, Justin Erenkrantz wrote:
> On Thu, Aug 02, 2001 at 07:46:38PM -0700, Ian Holsman wrote:
> > just a note for the person wanting to implement this in unix.
> >
> > in linux .. pthread_yield would be OK.
> > in solaris thr_yield should be used (as pthread_yie
Justin Erenkrantz wrote:
On Thu, Aug 02, 2001 at 07:46:38PM -0700, Ian Holsman wrote:
just a note for the person wanting to implement this in unix.
in linux .. pthread_yield would be OK.
in solaris thr_yield should be used (as pthread_yield isn't defined, and
posix threads are implemented onto of
On Thu, Aug 02, 2001 at 07:46:38PM -0700, Ian Holsman wrote:
> just a note for the person wanting to implement this in unix.
>
> in linux .. pthread_yield would be OK.
> in solaris thr_yield should be used (as pthread_yield isn't defined, and
> posix threads are implemented onto of LWP threads )
That sounds good to me. I'd submit a patch, but I have no idea how we'd
do Solaris vs. Linux detection with APR's preprocessor stuff. is there
a CPP symbol that we could use for this, or do we have to make one up?
-aaron
On Thu, Aug 02, 2001 at 07:46:38PM -0700, Ian Holsman wrote:
> just a note
just a note for the person wanting to implement this in unix.
in linux .. pthread_yield would be OK.
in solaris thr_yield should be used (as pthread_yield isn't defined, and
posix threads are implemented onto of LWP threads )
Justin/Aaron ???
[EMAIL PROTECTED] wrote:
bnicholes01/08/02 17:31:3
On Thu, Aug 02, 2001 at 11:16:46AM -0400, Jeff Trawick wrote:
> > I see your point. How about APR_UNDEFINED or APR_NOSTATUS?
>
> sounds reasonable to me
>
> > > Why would a "return NULL" instead of apr_thread_exit() imply exiting
> > > under error? It depends upon the app.
> >
> > I agree that
Aaron Bannert <[EMAIL PROTECTED]> writes:
> On Wed, Aug 01, 2001 at 05:21:52PM -0400, Jeff Trawick wrote:
> > Aaron Bannert <[EMAIL PROTECTED]> writes:
> >
> > > How about instead of assuming APR_SUCCESS we just leave it undefined?
> > > This seems counter-intuitive, in that a worker function tha
On Wed, Aug 01, 2001 at 05:21:52PM -0400, Jeff Trawick wrote:
> Aaron Bannert <[EMAIL PROTECTED]> writes:
>
> > How about instead of assuming APR_SUCCESS we just leave it undefined?
> > This seems counter-intuitive, in that a worker function that prematurely
> > returns (w/o calling apr_thread_exi
Aaron Bannert <[EMAIL PROTECTED]> writes:
> I posted a fix for this about a week and a half ago. The fix attempted
> to do the same thing on other platforms. Also, my fix made one extra
> change (that may or may not be agreeable to the group), and that was to
> change the prototype of apr_thread_e
Aaron Bannert <[EMAIL PROTECTED]> writes:
> How about instead of assuming APR_SUCCESS we just leave it undefined?
> This seems counter-intuitive, in that a worker function that prematurely
> returns (w/o calling apr_thread_exit()) was probably exiting under error.
What is an undefined apr_status_
How about instead of assuming APR_SUCCESS we just leave it undefined?
This seems counter-intuitive, in that a worker function that prematurely
returns (w/o calling apr_thread_exit()) was probably exiting under error.
-aaron
On Wed, Aug 01, 2001 at 04:54:58PM -, [EMAIL PROTECTED] wrote:
> traw
I posted a fix for this about a week and a half ago. The fix attempted
to do the same thing on other platforms. Also, my fix made one extra
change (that may or may not be agreeable to the group), and that was to
change the prototype of apr_thread_exit() so it takes an apr_status_t
instead of an (ap
> > > Argh! I also thought that the purpose of SMS was to replace
malloc/free
> > > and not pools. If you want to replace pools, then the code should not
> > > be called apr_sms_blah. Pool is the name for our memory system --
pool
> > > does not, and never has, defined the type of memory behind
> > Argh! I also thought that the purpose of SMS was to replace malloc/free
> > and not pools. If you want to replace pools, then the code should not
> > be called apr_sms_blah. Pool is the name for our memory system -- pool
> > does not, and never has, defined the type of memory behind it.
>
>
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > We could implement pool using sms but we'd loose a great deal
> > of flexibility
> > and a great opportunity to make APR even more useful.
> >
> > Pools are a single way of dealing with handing out memory. they imply a
> > degree of
On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> We could implement pool using sms but we'd loose a great deal of flexibility
> and a great opportunity to make APR even more useful.
>
> Pools are a single way of dealing with handing out memory. they imply a
> degree of overhead and w
On Thu, Jun 07, 2001 at 08:03:46AM -0700, [EMAIL PROTECTED] wrote:
>
> As it happens, this is exactly what I envisioned when SMS was first
> discussed. Namely, a new back-end for pools that can use any allocator.
ack. sorry for thinking otherwise.
luke
On Thu, Jun 07, 2001 at 09:27:00AM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 07, 2001 at 03:54:24PM +0200, Luke Kenneth Casson Leighton wrote:
> > only an SMS instance should know exactly how to deal with its
> > memory - _including_ locking - IF it is needed.
>
> Ah. I see the logic in that.
On Thu, Jun 07, 2001 at 03:54:24PM +0200, Luke Kenneth Casson Leighton wrote:
> only an SMS instance should know exactly how to deal with its
> memory - _including_ locking - IF it is needed.
Ah. I see the logic in that. Thanks for explaining. =)
Yes, the SMS should be the only one dealing wit
As it happens, this is exactly what I envisioned when SMS was first
discussed. Namely, a new back-end for pools that can use any allocator.
Ryan
On Thu, 7 Jun 2001, Luke Kenneth Casson Leighton wrote:
> > > See, that's where my overall view of "where we hope to get to" differs.
> > > In my m
> > As for locking, well the logical level for locking to be implemented is in
> > the sms module. Look at the standard module. malloc should be thread safe
> > so no locking should be required, hence we don't have any. In a tracking
> > system we can't guarantee that so we lock.
>
> I don't rea
> > See, that's where my overall view of "where we hope to get to" differs.
> > In my mind, APR depends on pools. Period. It would require a
> > major overhaul for most APR operations to be safe WITHOUT pools (ie, lots
> > of apr_sms_free operations would have to be added, which is exactly what
> then you could takle parts of the apr, for example strings
> replacing the 'standard' pool memory functions it uses with sms
> memory calls in their place, as long as the 'standard' and SMS memory
> have the same lifetime.
... i also should point out that your comment leads me to
believe that yo
On Wed, Jun 06, 2001 at 03:51:55PM -0700, Ian Holsman wrote:
>
>
> > -Original Message-
> > From: Sander Striker [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 06, 2001 3:13 PM
> > To: Cliff Woolley; David Reid
> > Cc: APR Development List
> &g
On Wed, Jun 06, 2001 at 04:34:22PM -0700, Justin Erenkrantz wrote:
> On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > This is the crux of the issue methinks. We don't yet have a module that
> > would allow us to even get close to replacing pools. We need a lot of
> > things from it
On Wed, Jun 06, 2001 at 05:35:43PM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > This isn't possible with pools. They limit you to a single way of getting
> > at your memory regardless of how it was obtained.
>
> What I basically said in my emai
> That implies that somebody has to alloc a lock outside, but we know that we
> can do that: an SMS around malloc(), a pool around that, then a lock using
> that pool. We can then pass that lock to SMS(my-custom-bugger).
this lock would be passed in as an argument to the initialisation /
creation
On Wed, Jun 06, 2001 at 05:35:43PM -0700, Justin Erenkrantz wrote:
> On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> > This isn't possible with pools. They limit you to a single way of getting
> > at your memory regardless of how it was obtained.
>
> What I basically said in my emai
On Wed, Jun 06, 2001 at 08:02:06PM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> > I think the thing is that I've seen the sms as slightly different than
> > what it was originally posted as. So, I might be in the minority
> > here. I think we are seeing two differen
On Wed, Jun 06, 2001 at 03:02:44PM -0400, Cliff Woolley wrote:
> On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
>
> > On Wed, Jun 06, 2001 at 06:12:17PM -, [EMAIL PROTECTED] wrote:
> > > - add an apr_pool_t to the sms structure
> >
> > -1 (non-veto, but awfully close). Uh, why are we doing th
On Thu, Jun 07, 2001 at 01:19:27AM +0100, David Reid wrote:
> This isn't possible with pools. They limit you to a single way of getting
> at your memory regardless of how it was obtained.
What I basically said in my email to David was that I could see having a
pool take in an option as to which S
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> Ah. Okay. I thought I've seen people say "-1 (non-veto)" before. Fine,
You have. We're inconsistent as usual. =-) Just thought I'd mention it
since it's been mentioned to me in a very similar situation.
> consider my vote -0.9 (because I'm
I've just replied to Justin direct, but I'll say it here as well...
We could implement pool using sms but we'd loose a great deal of flexibility
and a great opportunity to make APR even more useful.
Pools are a single way of dealing with handing out memory. they imply a
degree of overhead and wh
On Wed, Jun 06, 2001 at 08:02:06PM -0400, Cliff Woolley wrote:
> The group has told me before that, since all code matters require a
> consensus, -1 always means veto. If you really, really, really don't like
> it but don't want to veto it, use -0.5 or -0.99 or something. =-) Only
> in non-conse
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> I think the thing is that I've seen the sms as slightly different than
> what it was originally posted as. So, I might be in the minority
> here. I think we are seeing two different views of what an sms should
> be.
>
> My -1 was non-veto, so it does
> On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> > This is the crux of the issue methinks. We don't yet have a module that
> > would allow us to even get close to replacing pools. We need a lot of
> > things from it and Sander and I have had some good early
> discussions about
> >
On Wed, Jun 06, 2001 at 11:47:53PM +0100, David Reid wrote:
> This is the crux of the issue methinks. We don't yet have a module that
> would allow us to even get close to replacing pools. We need a lot of
> things from it and Sander and I have had some good early discussions about
> how it could
On Wed, 6 Jun 2001, Ian Holsman wrote:
> maybe you could take a bit at a time
> for example.. modify the pool code so that it has a 'sms' memory pointer
> in the structure, on init/destroy you also clean it up ..
> then you could takle parts of the apr, for example strings
> replacing the 'standar
> -Original Message-
> From: Sander Striker [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 06, 2001 3:13 PM
> To: Cliff Woolley; David Reid
> Cc: APR Development List
> Subject: RE: cvs commit: apr/threadproc/unix thread.c
>
>
> > On Wed
> On Thu, 7 Jun 2001, Sander Striker wrote:
>
> > Argh!!! [getting abit frustrated now, because there seems to be no
> > way of moving forward and thus proving the system]
>
> I think we're at least starting to face the issues head-on. We're making
> progress, believe it or not. =-)
Yes we are!
On Thu, 7 Jun 2001, Sander Striker wrote:
> Argh!!! [getting abit frustrated now, because there seems to be no
> way of moving forward and thus proving the system]
I think we're at least starting to face the issues head-on. We're making
progress, believe it or not. =-)
> > See, that's where my
> On Wed, 6 Jun 2001, David Reid wrote:
>
> > There is no pleasing some people is there??
>
> Nope. =-)
Argh!!! [getting abit frustrated now, because there seems to be no
way of moving forward and thus proving the system]
> > At present pools are a specific implementation of memory management.
On Wed, 6 Jun 2001, Cliff Woolley wrote:
> newstr = apr_pstrdup(apr_sms_t *mem_sys, char *str)
>
> because then you have to be sure to
>
> apr_sms_free(str)
Make that apr_sms_free(newstr). ;-)
--
Cliff Woolley
[EMAIL PROTECTED]
On Wed, 6 Jun 2001, David Reid wrote:
> There is no pleasing some people is there??
Nope. =-)
> At present pools are a specific implementation of memory management. In
> time we hope to get sms to a point where we can replace pools with an sms
> module that is better. When we get there, it wo
There is no pleasing some people is there??
Here I go with an explanation of why I made the change...
At present pools are a specific implementation of memory management. In
time we hope to get sms to a point where we can replace pools with an sms
module that is better. When we get there, it wo
On Wed, 6 Jun 2001, Justin Erenkrantz wrote:
> On Wed, Jun 06, 2001 at 06:12:17PM -, [EMAIL PROTECTED] wrote:
> > - add an apr_pool_t to the sms structure
>
> -1 (non-veto, but awfully close). Uh, why are we doing this?
> I thought that a pool would be defined in terms of a sms (not now, bu
From: <[EMAIL PROTECTED]>
Sent: Wednesday, June 06, 2001 1:12 PM
> This threw up an issue with locking, so next
>
> - change the locking code to add an owner and ref counting
> so we can lock multiple times from the same thread. this was
> needed by the apr_sms_tracking_reset code
On Wed, Jun 06, 2001 at 06:12:17PM -, [EMAIL PROTECTED] wrote:
> - add an apr_pool_t to the sms structure
-1 (non-veto, but awfully close). Uh, why are we doing this?
I thought that a pool would be defined in terms of a sms (not now, but
at some point). This would not allow that to happe
Apologies again for this being such a big commit :( I didn't want to commit
stuff before I'd finished, but kept finding more bits I had to do before I
was "finished".
Win32 and OS/2 need the changes I've made to the locking code...
david
On 25 Feb 2001 [EMAIL PROTECTED] wrote:
> trawick 01/02/24 17:24:37
>
> Modified:threadproc/unix thread.c
> Log:
> if we don't have the prototype, we shouldn't have the function either
>
> (haven't we been here before?)
We've been here hundreds of times, and we are likely to rever
52 matches
Mail list logo
