> 'use the EVT_TIMER macro to connect it to the event
> handler which will receive wxTimerEvent notifications.'
> This is the approach I have taken in my wxTimer usage, and this uses the
> main applications message loop to handle the timer notifications. Thus
> not making use of threads. The only instance where a threading issue may
I don't see the word 'thread' used anywhere here. As Vadim said, there
might be an extra thread involved or not. That is platform-dependent.
> arise in the use of the XmlRpc server is the following scenario
> XmlRpc call made
> wxTimerEvent issued
> WatchForXMLRPC run
> getXmlRpcServer().work(0.0) run
> User Starts Search
> XmlRpcServer runs the execute routine
> New chm file is loaded
> * app would crash.
> This scenario I cannot foresee occurring since XmlRpcServer directly
> processes the incoming request, without the use of threads, once
> XmlRpcServer::work() is called. Thus, the search button in the UI is
Oh. I actually did not know that work() does not involve a separate
thread. Well if you did all the research and are sure no problems can
arise, I'll probably tinker more with the code for a little while and
then get ready for releasing 0.9.5. Please let me know if you have any
doubts about stuff working somewhere in the code.
> blocked until the call to work() returns and therefore this causes no
> problem except for a delay in refreshing the interface while the search
> is running. In my eyes for the intended purpose this is quite acceptable
> at the moment, and if the search is limited to 500 items, this delay may
> only be momentary. This conservative approach can be improved in later
I've never seen a chm file which yielded more than 500 results. Most of
them don't even have that many htmls inside. I'll probably set up a
limit though, I'll think about it.
> development iterations, if required. For example, the code for the
> XmlRpc server could be run in a separate "worker" thread. GUI
> interactions could than be "queued" as input to the worker thread. The
> worker thread would process the queued requests and perhaps send back
> the results as events to the GUI layer. However, I think it is better to
> leave this optimization for later - if required.
That would bring about synchronization requirements from hell. That's
what I was trying to avoid in the first place. I believe it's better to
leave it to as few threads as possible :-).
> With regards to the issue of this same behavior under MacOS X it is
> based on a BSD core and should behave in the same manner as
> Solaris/Linux/BSD and Windows. If it does not, then the behavior would
> not be uniform across the wxWidgets framework. If so it should be
> pointed out to the wxWidgets developers so that the behavior is uniform
> and predictable across all supported platforms. Use of the XmlRpc
> functionality is not enabled by default and is purely optional to the
> end user, and could simply not be available to MacOS X users until
> wxWidgets resolves this issue.
It's not about consistency in that kind of detail. The wxTimer would
still act according to the documentation, just the implementation
details might differ. For example, the wxTimer might fire an event for
which wxWidgets created a separate thread for catching. That's certainly
a possibility, and if it happens like that, the scenario you described
above is very possible. That doesn't mean that the behaviour is
inconsistent, since I was unable to find anywere in the documentation
that the wxTimer event is supposed to be caught in the same thread in
which the wxTimer itself was created.
> Your friend mentioned the use of wxIPC for inter-process communications,
> I have unfortunately been unable to locate any documentation on this
> class and it's functionality through the wxWidgets website. The use of
> this class, if I understand it in concept, is that it is a platform
> independent wrapper for the local systems IPC routines. While this
> offers cross platform support it restricts applications wishing to
> communicate to xCHM to those which make use of the wxWidgets Framework
> and written in C++. The use of XmlRpc allows for applications of any UI
> library/framework and of any supported language to interface with xCHM,
> while requiring that a much smaller library be linked.
They're not very docummented :-). But there is a sample in the samples/
directory that illustrates their usage. It's in samples/ipc.
I don't really care about that issue though. The XMLRPC++ stuff actually
suits me better since if not detected on the system, xCHM remains the
same, but the wxIPC classes are always there if wxWidgets is there and
that code would have been harder to set aside and tear apart. The wxIPC
classes were just Vadim's suggestion. But I hope you do know that
there's wxPython so you're not stuck with C++ if you're using wxWidgets