[wx-dev] wxThread, thread local storage and wxLog

[Armel Asselin]

> AA> > And what will each small task do with its logs? If it can't show 
> them in
> AA> > the GUI?
> AA> imagine that I control two distinct processes, each with its log 
> window.
> AA> Messages will go to GUI but I want messages related to each small 
> tasks,
> AA> which may handled by any worker thread (to maximize throughput), to be 
> sent
> AA> to the right log window, the only way is to set the active target at 
> the
> AA> start of each task.
>
> No, not at all, you can use thread id perfectly well here and, in fact,
> this seems much more natural to me. And please don't say that "log itself
> must be aware of threads" when using the ids because it must be aware of
> them anyhow: how else are you going to separate messages from different
> threads in different windows?
ok, ok, so maybe this issue could be solve outside from the framework 
itself, if i make by myself a wxLog object which uses a wxTLS slot to store 
a job id (NOT a thread id), and then this wxLog is able to distribute to the 
right log window, it could be ok.

> AA> having a wxTLSSlot is perfectly ok but wasn't the templates a bit
> AA> persona-non-grata in wx? did it change?
>
> I think simply templates like this are supported by all compilers. After
> all this is not more (and in fact much less) than, say, std::string uses
> and we do support build mode in which we use it now.
having a wxUSE_STL mode does not mean it is the -only- mode. to be honest I 
really do not care using templates or not, I have plenty of them everywhere 
needed in my code but i just do not want to create new problems.

> AA> if I do not store the stuff in system TLS, i must store it somewhere? 
> no?
>
> Who is "you"? I was speaking about wx and wx should store all
> thread-related data in a struct (not array!).
>
> AA> and there is a wxThread object per thread already (only main thread 
> does not
> AA> have),
>
> Well, and how do you think this wxThread object is associated with each
> thread? Using TLS, of course.
aaarrrghhh, you tell not use _more_ tls entries because the developper using 
wx could exhaust the system tls, so I think of a solution to reuse in some 
manner the wxThread object (and add there the pointer to wxTLS which has to 
contain a per-thread array with wxTLS entries), and then you tell me "hey 
just use system tls". we have to choose one or the other.

another reason from the wxTLS implementation point of view, if I could avoid 
having per-platform sources by just using a single pointer in a wxThread 
object, it would make me really happy. from a user point of view, having 
wxTLS independent of wxThread would allow one without the other, potentially 
useful when using a log inside a component launched from an application 
which is not wx aware (is there already something which creates a dummy 
wxThread object on the fly for threads which do not have one?).

just a note, it would be really cool if the wxTLS could auto-delete the 
objects put inside if the user wants it, many objects have no particular 
opportunity of running code and release resources near the thread end.

> AA> and is there a system TLS on all the systems that wx want to support?
>
> Yes, both Win32 and pthreads have it.
cool

> AA> and it would be really cool to have at least that working for users 
> who do
> AA> not want to know about SetActiveLogTargetPerThread? no?
>
> Sorry, but how can we make it simpler to set a per-thread log target than
> by calling SetActiveLogTargetPerThread()? What exactly do you propose?
>
> AA> wxLogNull is used internally by wx... it means that simply calling wx
> AA> stuff, can give weird results in multi-threaded apps.
>
> This is an argument for wxLogNull to use SetActiveLogTargetPerThread()
> (and not the global SetActiveTarget()), yes.
wxLogNull does not use SetActiveTarget at all currently. but if it was 
derived from wxLog and if it installed itself with 
SetActiveLogTargetPerThread, ok. note, that this issue could as well be 
solved with wxTLS entry containing an equivalent for the ms_doLog boolean.

Armel