On Mon, 2007-09-17 at 07:15 -0700, Doug Baskins wrote:
> John:
>
> > Word_t *pshape= (Word_t*)JudyLGet(j_shape,(Word_t)memory,&je);
> > if(pshape==NULL||pshape == (Word_t*)(void*)PPJERR) abort();
>
> I have been considering on getting rid of the PJError_t parameter in
> the
> Judy routines that do not malloc(2). It seems that nobody uses it.
Yeah, I know. I suspect the main use is when using a debugger,
if you set it to a static variable, you can then examine the
variable easily. So it may not be entirely useless.
> Judy returning a -1 in the "pointer to value" word do so because:
>
> 1) There was a malloc(2) failure.
> 2) There was a Judy array corruption.
> 3) There was a programming mistake.
Are you sure? Because I have correct code, which doesn't work
UNLESS I also check for the "-1 in a pointer".
That was the problem I had. I was checking ONLY for NULL,
and I was getting a segfault .. it turned out to be the -1
was returned..
.. but I could be confused because I ALSO did initially have
another bug in my code (passing a pointer to a Judy array
instead of the actual Judy array, which is itself just a pointer).
If you're right, I can remove the -1 check. (But I tried that,
and stuff failed which works with the check .. if my code
was bugged it wouldn't work, even with the check..)
> Word_t *pshape= (Word_t*)JudyLGet(j_shape,(Word_t)memory,NULL);
>
> Judy was designed to have a zero (NULL) in the error parameter place.
OK, but my Judy calls in the Felix RTL are all done by C++
member functions of the 'garbage collector' object, so having
a slot for the judy error code is no problem.
however it is never examined. Probably it should be to
check for malloc failure (but I'm lazy .. :)
> One of the original (perhaps misguided) reasons for the -1 return was
> to avoid the "core dumps" from within the Judy code. I got tired of
> explaining to programmers that it was their error in the calling
> parameters.
Hehe.. I understand :)
One solution is to provide an error function HOOK, this is a user
supplied function like:
void bug(int code, void *judy_array, void *client_data)
{
fprintf(stderr, "Got Judy Error %d on %p\n",code,
judy_array);
abort();
}
In C++ you might throw an exception. The default should be to
print a diagnostic on stderr and core dump.
If this is a malloc failure, the bug() routine could return,
in which case the Judy should retry the malloc(). The user
routine could free up some memory.
[This is only a crude sketch .. don't implement it directly as
described!]
You already have an allocator hook, right?
> As for your mistake with JudyLGet(), we all have done it and I have
> considered
> changing interface.
No: the interface is correct. I mean, the way the types are handled
is quite messy and might be improved, although C makes it hard,
however ..
> The design of JudyLIns() requires the "&" so that the
> "allocate the array with NULL pointer" property of Judy can be used.
Indeed. And the others don't have the & which is also correct,
because they don't add or delete from the array, in particular
not an empty array.
In Felix binding to Judy (not in the run time system)
I wrapped away this quirk, but that was a design choice,
and one I could make because Judy DIDN'T try to be nice.
> Again, this was not done originally because of the additional overhead
> of a subroutine call -- no longer significant in a modern processor.
Rot :) An extra indirection can easily matter in a time critical
routine like a garbage collector. But the REAL reason you did it
the way you did was because you got it right... :)
> The Judy macros (JLG() etc.) were an attempt to avoid that mistake,
> but
> it seems that programmers don't like using them for reasons I don't
> understand.
Macros suck. You macros are horrid .. :) The thing is you didn't
document them correctly, because it was 'obvious' to you.
In some case the macros require an lvalue, not a value,
and that isn't explained anywhere.
The man pages document the macros, and even the website does
them first, then shows which functions they use.
The functions are the critical thing. The standard judy header
shouldn't contain the 'convenience' macros, put them in
another header so they can be used or not at the client's
discretion.
> On another subject, you suggest the JudyLNext() return some
> stateful information -- for performance. I studied that very
> extensively 6 years ago to improve the performance on Next/Prev.
> Again, on a modern processor, these routines almost always run when
> the
> data is "in the cache" and they almost disappear from the profiles.
> (Having stateful information does not help in avoiding cache misses).
Yes, good point! And the state object will also use up cache,
and may interfere with performance.
> I am still actively working on a new Judy. Improved speed was the
> highest objective, but it looks like greatly improved memory
> efficiency
> will be the biggest improvement.
Cool!
> I take your suggestions very seriously, so keep them coming.
Sure .. I love complaining :)
> Nobody likes the Judy semantics,
huh? The semantics are right. Its the docs and the types that
aren't so hot. Even the names of the routines are confusing
to me.
I wrote the same set of routine MANY times in the past when
designing indexed files (in the old days before databases).
You have first, last, next, previous, next_or_equal,
previous_or_equal, and get_equal which correspond to the
ordering terms:
0 inf > < >= <= ==
so I would have called the routines more like:
first, last, gt, lt, ge, le, eq
but this along with most of my other complaints are presentation
issues NOT semantics.
> The latest wrinkle with C++ not compatible with Judy is troublesome
> for me.
I forget what that is?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
