Wed Jun 15 17:58:08 CEST 2011
I can only give you my experience with wxWidgets.
I developed a small application with wxWidgets (SLOC - 198k). It was
written in a much older version of wxWidgets but has been upgraded all
the way to wxWidgets 2.8.10. The application was developed under VC
2005 on Windows. It's in daily use by approximately 10,000 users with
no reported faults on every OS from Windows 95 (don't ask) all the way
to Windows 7, and Windows 2000 Server to Windows 2008 Server.
At no time have I had a crash that wasn't found to be my fault.
But, I learned very early on that wxWidgets is like virtually all C/C++
GUI APIs. Handling multi-threading has to be handled very carefully.
The application has 15 main threads interacting heavily on a core set of
data. Changes in that data can cause MVC (model/view/controller)
updates that reflect updates into the wxWidgets GUI world. It is very
important that thread 'x' doesn't call any wxWidgets functions but
instead send messages or signals of some kind to the 'single' GUI thread
that handles all GUI updates. Forgetting that even once can cause a
crash an hour later due to GUI data corruption. Experience was a great
My gut feeling is that your idea of putting the GUI in a separate
process would help. It would enforce a more single threaded view of the
world in the GUI. But there's a lot of data that would have to be
transferred back and forth to the wxWidgets process. As an example, my
application has a wxGrid object (similar to a spreadsheet) that can have
several thousand rows and columns with each cell being up to 1000 bytes.
That ends up being megabytes of data that have to be transferred back
and forth potentially multiple times a second. It can be done, just how
to do it efficiently and fast.
I'm not sure that answers all your questions, Robert but it's a start.
On 6/15/11 7:35 AM, Robert Virding wrote:
> The wx application binding of wxWidgets seems to be cause crashes on many systems, including MacOSX. After pondering on it I have a number of questions:
> Is it the wxWidget implementation itself which is buggy?
> Is the use of them directly in the BEAM which causes the crashes? Either through some inherent match problem, or version mismatch, or ...?
> If it is the second, would implementing a completely separate wx process solve the problem? I.e. would it be possible to implement such a process which would make linking with wxWidgets "safe"?
> If so, wouldn't it be better to do just that? Run wxWidgets in a separate OS process and use a (non-linked in driver) port to access it? Yes, it would be slower but it would work and be more robust.
> If this has already been discussed and my questions answered please point me in the right direction.
> erlang-questions mailing list
More information about the erlang-questions