davidelang
commented
7 years ago On Mon, 31 Oct 2016, Emiel Bruijntjes wrote:
We have some issues with converting the json tree to a string from multiple threads at the same time. I think the problem is with the printbuf member that is being used by two threads. We will probably be able to work around this, but after looking at the code, I think it is a peculiar design that the output buffer is part of the json_object.
double check if you are really having this problem with libfastjson. This is exactly what we were fighting with json-c that triggered the fork to create libfastjson. Your solution may be better than the fix that Rainer put in place, but you shouldn't be running into that problem with the current libfastjson
David Lang
What would you think of adding the following functions to libfastjson:
/** * Signature of a custom print function that can be implemented by the user. * @param ptr user-supplied pointer * @param buffer buffer to be written * @param size size of the buffer * @return size_t number of bytes written */ typedef size_t (fjson_print_fn)(void *ptr, const char *buffer, size_t size); /** * Write the json tree to a user-supplied function * @param jso the fjson_object instance * @param func the user supplied function to which all data will be passed * @param ptr user-supplied pointer that is passed as first param to the callback * @returns the number of bytes written */ extern size_t fjson_object_write(struct fjson_object *jso, fjson_print_fn *func, void *ptr); /** * Extended write function that allows extra flags to be passed * @param jso the fjson_object instance * @param flags formatting options, see FJSON_TO_STRING_PRETTY and other constants * @param func the user supplied function to which all data will be passed * @param ptr user-supplied pointer that is passed as first param to the callback * @returns the number of bytes written */ extern size_t fjson_object_write_ex(struct fjson_object *jso, int flags, fjson_print_fn *func, void *ptr);This would allow users to supply their own output function, for example to write the json to a FILE*, or to write it to a fixed size buffer on the stack or to a dynamically growing buffer just like the current "struct printbuf" does. In fact, the "printbuf" implementation could be implemented on top of these functions.
This will often also be a performance improvement because now we're always stuck with the dynamically growing printbuf -- even if we have a pretty good idea how big the output is going to be, or when we want to write to a file instead of to a dynamically allocated buffer.
Are you willing to accept a pull request that implements this?
rgerhards
Hi Rainer,
We have some issues with converting the json tree to a string from multiple threads at the same time. I think the problem is with the printbuf member that is being used by two threads. We will probably be able to work around this, but after looking at the code, I think it is a peculiar design that the output buffer is part of the json_object.
What would you think of adding the following functions to libfastjson:
This would allow users to supply their own output function, for example to write the json to a FILE*, or to write it to a fixed size buffer on the stack or to a dynamically growing buffer just like the current "struct printbuf" does. In fact, the "printbuf" implementation could be implemented on top of these functions.
This will often also be a performance improvement because now we're always stuck with the dynamically growing printbuf -- even if we have a pretty good idea how big the output is going to be, or when we want to write to a file instead of to a dynamically allocated buffer.
Are you willing to accept a pull request that implements this?