On Thu, 20 Sep 2018 19:55:41 +0300
"Yordan Karadzhov (VMware)" <y.karadz@xxxxxxxxx> wrote:
> The TODO message states that we have to understand why racecmd_read_at()
> is not thread-safe and see if this can be fixed. We now know why and we
> know that this cannot be fixed.
I wouldn't say that it can not be fixed, but that it's hard to fix.
I'll update the change log.
Thanks!
-- Steve
>
> Signed-off-by: Yordan Karadzhov (VMware) <y.karadz@xxxxxxxxx>
> ---
> kernel-shark-qt/src/libkshark.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel-shark-qt/src/libkshark.c b/kernel-shark-qt/src/libkshark.c
> index 3635b48..506511d 100644
> --- a/kernel-shark-qt/src/libkshark.c
> +++ b/kernel-shark-qt/src/libkshark.c
> @@ -842,9 +842,8 @@ struct tep_record *kshark_read_at(struct kshark_context *kshark_ctx,
> uint64_t offset)
> {
> /*
> - * It turns that tracecmd_read_at() is not thread-safe.
> - * TODO: Understand why and see if this can be fixed.
> - * For the time being use a mutex to protect the access.
> + * Calling tracecmd_read_at() is not thread-safe. Use a mutex to
> + * protect the access.
> */
> pthread_mutex_lock(&kshark_ctx->input_mutex);
>
|