qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] glib: add g_thread_new() compat function


From: Michael Tokarev
Subject: Re: [Qemu-devel] [PATCH 2/3] glib: add g_thread_new() compat function
Date: Fri, 02 May 2014 15:16:18 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0

02.05.2014 15:08, Peter Maydell wrote:

>>> Stefan Hajnoczi:
>>>> +#if !GLIB_CHECK_VERSION(2, 31, 0)
>>>> +static inline GThread *g_thread_new(const gchar *unused,
>>>> +                                    GThreadFunc func,
>>>> +                                    gpointer data)
>>>> +{
>>>> +    GThread *thread = g_thread_create(func, data, TRUE, NULL);
>>>> +    if (!thread) {
>>>> +        g_error("g_thread_create failed");
>>>> +    }
>>>> +    return thread;
>>>> +}
>>>> +#endif
>>>
>>> About g_error():
>>>
>>> "This function will result in a core dump; don't use it for errors you 
>>> expect.
>>>  Using this function indicates a bug in your program, i.e. an assertion 
>>> failure."

> I'm not convinced we should be emitting any kind of
> warning message here anyway -- surely it's up to the
> caller to handle thread creation failure? The glib
> warning/error functions presumably print to stderr,
> which has all the usual issues with possibly messing
> up guest output.

Note that QemuThread &Co has exactly the same issue.

void qemu_mutex_init(QemuMutex *mutex)
{
...
    if (err)
        error_exit(err, __func__);
}

and so on in all util/qemu-thread-{posix,win32).c

But yes, you're right, at least coroutine-gthread.c
appears to try to handle errors by its own.

So this is what's missing from my patchset for libcacard -
since this one replaces qemu thread primitives (which
aborts on error) with glib thread primitives (which
return error condition instead).

Thanks,

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]