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

[Armel Asselin]

> AA> doing this mean that the log itself must be aware of what to do of the
> AA> results coming from a particular thread
>
> What do you mean by "aware"? It would just show the thread id in addition
> to the message.
>
> But generally speaking, yes, the main program should know about its
> threads. This makes sense to me.
>
> AA> use my thread(s) to execute small tasks which may be relative to 
> different
> AA> bigger tasks, and the log target should be bound to the big task... 
> only
> AA> each small task will know.
>
> And what will each small task do with its logs? If it can't show them in
> the GUI?
imagine that I control two distinct processes, each with its log window. 
Messages will go to GUI but I want messages related to each small tasks, 
which may handled by any worker thread (to maximize throughput), to be sent 
to the right log window, the only way is to set the active target at the 
start of each task.
>
> AA> yes it is low level and i'd be perfectly ok to use _in addition_ your
> AA> template based stuff.
>
> I'd also prefer to have a separate wxTLSSlot class (which I called
> wxThreadSpecificUntypedData last time) in addition of adding extra methods
> to wxThread. I didn't understand your argument against having a separate
> class to be honest.
having a wxTLSSlot is perfectly ok but wasn't the templates a bit 
persona-non-grata in wx? did it change?

> AA> note that I did not intend to store all of that stuff in the system 
> TLS
> AA> (because of the potential limitations that you cited), but storing a
> AA> wxArrayPtr or something similar in the wxThread object.
>
> Sorry, I'm lost. Why would you need an array in wxThread?
if I do not store the stuff in system TLS, i must store it somewhere? no? 
and there is a wxThread object per thread already (only main thread does not 
have), and it has the right granularity. we could also use a true entry in 
the system TLS for a wxTLS object, but what advantage? and is there a system 
TLS on all the systems that wx want to support? this is probable but at 
least i do not know how it works on non-Windows OS yet.

> AA> it will indeed fix the wxLogNull enable/disable pairing issue _if we 
> put at
> AA> least a redirecting log target per thread_ so should not we at least 
> add
> AA> that, from a user point of view it would not change anything? no?
>
> I'm even more lost. What do you mean?
when you use threads, you want potentially to launch prospective tasks, for 
example you could try a computation and if there is a problem or something 
which needs user intervention you bail out that's all. in this case, you may 
not want these tasks to pollute the logs. there you use wxLogNull... but if 
the active log target is shared, and as wxLogNull is not thread safe 
everything goes wrong. Note that using some new 
wxInterlockedIncrement/Decrement API and counting rather than booleans for 
this may as well work (and it would be far easier to implement), it would 
not be perfect though (messages coming from threads with no wxLogNull in 
effect would be blocked as long as any thread as one).
what i want to underline here, is that in multi-threaded apps, if not simply 
logging to a single global log, current logging is somewhat inappropriate, 
even for a simple wxLogNull.
and it would be really cool to have at least that working for users who do 
not want to know about SetActiveLogTargetPerThread? no?

wxLogNull is used internally by wx... it means that simply _calling_ wx 
stuff, can give weird results in multi-threaded apps.

Armel