[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] dynamic trace buffer resizing |
Date: |
Mon, 12 Aug 2013 22:13:11 +0200 |
User-agent: |
Mutt/1.4.2.3i |
On Mon, Aug 12, 2013 at 03:10:59PM -0500, Jim Ursetto wrote:
> On Aug 12, 2013, at 2:11 PM, Peter Bex <address@hidden> wrote:
> >> Looks useful. Could it perhaps be more useful to make the argument
> >> to C_resize_trace_buffer a regular size_t instead of a Scheme fixnum?
> >> That might make it slightly more usable from an embedded situation.
>
> Sure -- but C_trace_buffer_size is an int. That's why I used int ;) I could
> certainly fix that at the source, shall I?
That would be great.
> > Also, why is a maximum size necessary, and why is it so small?
>
> It's not. But there's a minimum size, so I figured naturally there should be
> a maximum size, if only to eliminate accidentally or maliciously resizing the
> trace buffer to an arbitrary extent. There are also max caps on some other
> resources. Since it's a ring buffer, I suppose there are no *performance*
> problems with a trace buffer of large size, just potentially memory usage.
> The default is also arbitrary. I could either eliminate the limit or raise
> the default, your call.
The other limits annoy me equally ;) So I guess it's probably enough to
have a minimum, or even rip that out as well (minimum of 0 = no history),
but I'm afraid that'd be more difficult.
> Actually, I just realized the arg isn't checked to be a fixnum. I'll change
> that when I incorporate any suggestions.
Ah, well spotted!
Cheers,
Peter
--
http://www.more-magic.net