how are zlog_category_t objects to be managed? about zlog

[meffie]

It seems to me the application should be able to specify a category by an application defined integral constant when logging.

It occurs to me, since the categories are named, and have wildcards and such, perhaps the category objects would be just cached by zlog and the logging api would just give the category by name (as as const char*). zlog would create the object on a cache miss. This seems to be a much easier API for real-world programs. Just a thought.

[HardySimpson]

Happy you like my project.

The zlog_category_t objects, are actually stored in a global hash table by zlog library.
After zlog_get_category(), you don't need to worry about release them. They will be released by zlog_fini() at last. So I think, the best way of using zlog category object maybe your plan (a). The global extern variables is not so bad. So a real world example maybe like

in main.c

zlog_category_t *xx;
zlog_category_t *yy;
zlog_category_t *zz;

int main(void)
{
    r = zlog_init();  assert(r);
    xx = zlog_get_category("xx"); assert(xx);
    yy = zlog_get_category("yy"); assert(yy);
    zz = zlog_get_category("zz"); assert(zz);

    // do the work here.

   zlog_fini();
}

int log.h

#include "zlog.h"
extern zlog_category_t *xx;
extern zlog_category_t *yy;
extern zlog_category_t *zz;

in xx.c

#include "log.h"
int xx(...)
{
    zlog_info(xx, "output of xx");
}

Just as you said, category object is cached

zlog_get_category("aa");  // find no aa in hashtable, create aa object and store it on hashtable
zlog_get_category("bb");  // find no aa in hashtable, create bb object and store it on hashtable
zlog_get_category("aa");  // find aa object in hashtable, return the aa object.

That's exactly how it works.

And back to the topic. The design of read-write lock doesn't quite satisfy me.
But when in multi-thread programming, lock is the only way of keep each thread safe as far as I know.

The classical stdio FILE *fp faces the same problem as zlog. It read a const char *path and return a pointer. It uses lock too. At the same time, stdio provide buffers to merge multiple small write() to a big one. So at last it engages more throughput and low latency with the cost of CPU-lock and memory-buffer.

I've been thinking about some async io solutions and multi-thread conditions. However there is no perfect idea. Perfect design maybe not exist except iphone...
Maybe after I study many real-world example of multi-thread promgramming I can give a better design.

[meffie]

Thanks.

The global extern variables is not so bad.

Well, I strongly disagree with this point. Requiring globals is a hint at a serious problem with the API and strains my confidence in the zlog library.

However, at least the document for version 1.x could show a real-world example.

After zlog_get_category(), you don't need to worry about release them.

Yes, that is my understanding now, but it's not clear from the documentation. When a library returns a pointer to an object, normally a program expects an API like "put" that releases the object from the "get". That is the conventional way in C.

---

I'd say a more sensible API in a future version would pass the category name as a string (const char*) and let zlog manage the objects in a thread-safe way. For example:

zlog_info("core", "starting the core system");
zlog_debug("core", "another message");

the zlog () call would obtain a read-lock to lookup the category by name, and if not in the cache (because this is the first call to zlog with that category name), convert the read-lock to a read-write-lock to update the cache. All subsequent calls would be under the read-lock.

This would avoid the application needing to create a bunch of global variables and would be safer for zlog, since currently the application has pointers to it's internal use category objects, which is dangerous for the zlog library.

Thanks for your work on zlog. I hope this is helpful.

Thanks,
Mike

[HardySimpson]

Your solution is safe, but low efficient.

In each call like this,
zlog_debug("core", "another message");

It costs a hashtable look up for "core" category. which is slow. Can you image a world with the stdio library like this?

fprintf("path/to/file", "aabbcc\n");
fwrite("path/to/file", "xxxxxx", 6);

Yes pointer to object is dangerous, but most C library provide object in this way.
zlog's object is a little different, as you don't need to release it by hand until zlog_fini(). The API is hard to design with thread-safe. So I think maybe the best way is give the choice of how to make thread-safe back to user's code.

[Hitobat]

Depending on your use-case, you could use lazy initialization to create and then cache a category for each code module. The first call into your module will then create the category, but must be after a zlog_init call.

Hopefully your compiler will optimize the cat() method to inline, but if not you could write a macro instead.

e.g. myModule.c :

#include "zlog.h"

static zlog_category_t* cat()
{
    static zlog_category_t *myModCat = NULL;
    if (myModCat== NULL)
        myModCat = zlog_get_category("myModule");
    return myModCat;
}

void myModule_someFunc()
{
    zlog_info(cat(), "Doing something");
}

[zwieberl]

I strongly agree with meffie that global extern variables are not a good solution!
Right now, I'm using the suggestion from Hitobat (thanks for that!), which works. I just added a #define cat cat() to avoid the brackets when calling zlog_info.
But this is work that shouldn't be done by the users of zlog, in my opinion.

[wenmingw120]

您好，请问下使用#define cat cat() 后 进行log输出如zlog_info(cat,"%s%d",“zlog test”,1111) 在进程中的多个模块中使用多种不同的roles输出不同的log文件时还是要指定category的名字，不然怎么知道要调用那个category的对象，这样用户使用起来还是比较麻烦，请问有没更好的办法处理category的对象？