Menu
▾
▴
1 Attachments
#1401 changes needed in order to support wxWidgets 3.0
hi, if the recent cvs version is complied with wxwidgets 3.0 installed on the computer, the resulting binary crashed with the first plot to the wxt terminal. (Crash report is appended.)
This happens regardless of wxwidgets 2.8 also being installed or not. Only after removing the 3.0 package can i make a working build with wxt.
Is wxwidgets 3.0 supposed to work?
Thread vs. process: a lot of those advantages/disadvantages are obviated by systems with multiple cores. E.g., context-switching isn't needed so often if a process doesn't have to give up its CPU. (Although, in Linux processes sure bounce around a lot from CPU to CPU, but that could be just for compilation where one file finishes then another starts...which is typically when I'm sitting watching the system monitor.) We know pipes are slow, but are sockets too? Super-efficiency hasn't been a major goal of gnuplot, even though it is pretty good; it's the graphics and terminals that are slower.
OK, I've gotten over another hurdle by establishing a socket connection between wxt_term (the client) and gnuplot_wxt (the server). The client/server code is pretty simple in the end, but it was a bit tricky in the sense that the example programs have a main visible window and are interactive so that the server is well established before there's any attempt to access that server. Some things I had to do:
Deal with a race condition between launching the external gnuplot_wxt process. The client Connect returns an error if the server is not available at the socket--an error which is not the same as "time out". So, we can't attempt a connect then wait (the usual steps), but have to keep trying to connect with the "wait" flag. I implemented attempted-connect every 1/10 second for 3 seconds. Seems robust.
Create a bogus main frame because if there are no windows after wxtApp::OnInit() the application automatically quits. (That in fact is the only robust way to exit; destroy all windows.) For now, the client sends an 0xAA to the server which then destroys the socket and destroys the main frame. This ensures that the socket will be available again immediately and that there is no zombie server complicating the next invocation.
Ensure that all plot windows use wxTheApp->GetTopWindow() (i.e., the main frame) as the parent. Thus, destroying GetTopWInodw() will destroy all windows and exit the process.
The client sends a 0xBE (a temporary value) to the server in order to display the "Hello World" window. (The blank one, not the one with the white background and plot.)
The ZIP file attached is similar to the previous. Follow the steps in the previous post for building. There are some wxLogMessages in the code, so one can read the messages that are appearing at the server and look for the associated code in gnuplot_wxt.cpp.
So the next hurdle is somehow encoding/sending the appropriate actions from client to server. After that it will be downhill or coasting because it is simply a matter of calling the appropriate code on the server side that is currently being done on the client side (and will eventually be discarded). It would be nice to set things up so that the client/server could send graphics events pretty much the same way as they currently are done across threads. There doesn't seem to be such a thing though. I'm open to ideas.
Another possibility to solve that GUI-event-loop-has-to-be-in-main-thread problem might be to do exactly that: have the event-loop in the main thread and move the gnuplot core to the second. Or alternatively, as is done on Windows, embed the event-loop calls in xx_waitforinput() (and some other sites like pause, sleep etc.).This is sort of "cooperative multitasking", so the first option might actually be better.
That's something possible to do, but I'm against that because it's then making gnuplot an all-out wxWidgets application. The model you describe is the model used for Octave's new GUI/framework. It uses Qt as the main process and puts the core program in a worker process. It's a good model for that, but not here because gnuplot is not a GUI.