Following are snippets of Vadim Zeitlin's reply to my email about thread
issues in the xCHM/XML-RPC++ code. Obviously the solution implemented is
not thread safe as it is now. Synchronization/more thought is needed.
-------- Original Message --------
Subject: Re: I'm lost
Date: Sat, 11 Sep 2004 00:18:28 +0200 (Romance Daylight Time)
From: Vadim Zeitlin
To: Razvan Cojocaru
RC> So they decided to use XML-RPC++ for xCHM/their application
You could tell them about wxIPC classes...
RC> If a command
RC> for loading a page from a chm file arrives, xCHM loads the chm file and
RC> displays the page. So far so good. But what happens if xCHM is in the
RC> middle of a lengthy search, and the timer event comes asynchronously,
RC> and xCHM has to load a different chm file than the one loaded (the one
RC> it's searching in)? Is that possible? Is the main thread interrupted
RC> temporarily, then the new chm loaded, then the search resumes only to
RC> find that it doesn't have anything to search in? Or the timer event can
RC> only occur when the application is doing nothing (i.e. the application
RC> cannot be in a search if the timer event occured)? Is this safe in any
RC> way? Because it doesn't seem safe to me.
It probably depends on the platform. Under MSW it is safe because timer
events are only dispatched from the main event loop. I'm almost sure it's
the same under GTK+ but I don't know about Mac.
RC> Is there a separate thread involved?
Not but using a separate thread (waiting on XML-RPC++ channel and posting
an event to the main thread to execute commands it receives) would surely
be a better solution than a timer.