Hallvard Breien Furuseth:

wietse@porcupine.org writes:

...

Hallvard Breien Furuseth:

...

/** User-settable callback for assert(), called before abort()

• instead of printing the message.
• assert(some user errors) might be unaffected. This hack
• should become obsolete as lmdb's error handling matures.
• @param[in] msg The assertion message, not including newline.
• @parem[in] info Currently NULL. Might change in the future.

*/ extern void (*mdb_assert_cb)(char *msg, void *info);

(Or maybe call it -before- printing the message, you can abort or longjmp yourself if you don't want the message.)

Looks good. I'll code up an example implementation to set and use the callback. The "info" argument should be sufficient to figure out which database is failing.

To repeat, 'info' would be NULL initially. Does that make it useless to you? Various pieces of code don't know any context of interest to the user anyway.

That is unhelpful, as my opens lots of databases.

Instead I propose that for each open database I give you my function pointer AND my context pointer. Then, you call my function with my context pointer when there is a problem.

My program opens multiple databases. It is useless if you pass me your LMDB handle, as I now have to find out a) which of all my open databases is LMDB and b) which of those LMDB databases is messed up. That totally breaks all abstractions.

I suppose we could s/assert(foo)/mdb_assert(mc, foo)/ when that compiles so it can report env, txn, dbi. Howard, should I do that?

That was my idea. Allow me to code up an example, it is simpler than arguing in the abstract.

Wietse