git.saurik.com Git - wxWidgets.git/blame_incremental

... / ...

Commit	Line	Data
	1	\section{Multithreading overview}\label{wxthreadoverview}
	2
	3	Classes: \helpref{wxThread}{wxthread}, \helpref{wxMutex}{wxmutex},
	4	\helpref{wxCriticalSection}{wxcriticalsection},
	5	\helpref{wxCondition}{wxcondition}
	6
	7	wxWidgets provides a complete set of classes encapsulating objects necessary in
	8	multithreaded (MT) programs: the \helpref{thread}{wxthread} class itself and different
	9	synchronization objects: \helpref{mutexes}{wxmutex} and
	10	\helpref{critical sections}{wxcriticalsection} with
	11	\helpref{conditions}{wxcondition}. The thread API in wxWidgets resembles to
	12	POSIX1.c threads API (a.k.a. pthreads), although several functions have
	13	different names and some features inspired by Win32 thread API are there as
	14	well.
	15
	16	These classes will hopefully make writing MT programs easier and they also
	17	provide some extra error checking (compared to the native (be it Win32 or Posix)
	18	thread API), however it is still a non-trivial undertaking especially for large
	19	projects. Before starting an MT application (or starting to add MT features to
	20	an existing one) it is worth asking oneself if there is no easier and safer way
	21	to implement the same functionality. Of course, in some situations threads
	22	really make sense (classical example is a server application which launches a
	23	new thread for each new client), but in others it might be a very poor choice
	24	(example: launching a separate thread when doing a long computation to show a
	25	progress dialog). Other implementation choices are available: for the progress
	26	dialog example it is far better to do the calculations in the
	27	\helpref{idle handler}{wxidleevent} or even simply do everything at once
	28	but call \helpref{wxWindow::Update()}{wxwindowupdate} periodically to update
	29	the screen.
	30
	31	If you do decide to use threads in your application, it is strongly recommended
	32	that no more than one thread calls GUI functions. The thread sample shows that
	33	it {\it is} possible for many different threads to call GUI functions at once
	34	(all the threads created in the sample access GUI), but it is a very poor design
	35	choice for anything except an example. The design which uses one GUI thread and
	36	several worker threads which communicate with the main one using events is much
	37	more robust and will undoubtedly save you countless problems (example: under
	38	Win32 a thread can only access GDI objects such as pens, brushes, \&c created by
	39	itself and not by the other threads).
	40
	41	For communication between secondary threads and the main thread, you may use
	42	\helpref{wxEvtHandler::AddPendingEvent}{wxevthandleraddpendingevent}
	43	or its short version \helpref{wxPostEvent}{wxpostevent}. These functions
	44	have a thread-safe implementation so that they can be used as they are for
	45	sending events from one thread to another. However there is no built in method
	46	to send messages to the worker threads and you will need to use the available
	47	synchronization classes to implement the solution which suits your needs
	48	yourself. In particular, please note that it is \emph{not} enough to derive
	49	your class from \helpref{wxThread}{wxthread} and
	50	\helpref{wxEvtHandler}{wxevthandler} to send messages to it: in fact, this does
	51	\emph{not} work at all.
	52
	53