Should have an option to ask to render when pressing F6
I've investigated ways to safely kill a thread. One theoretical way I found
(for pre-emptive thread cancellation) is gcc specific, requires compiling
all libraries with special experimental codegen flags, probably requires
additional magic, not worth discussing. A more feasible way is cooperative
thread cancelation where the code you want to interrupt periodically checks
a global or thread-local 'cancellation' variable: this requires changes to
CGAL which are at least partially in progress. Maybe this support finally
arrives, but then you want to replace CGAL with a faster rendering library
with the same problem: then what? Or you could run CGAL in a separate
process, and kill the process if cancelled by the GUI process.
On 20 February 2017 at 14:58, Marius Kintel marius@kintel.net wrote:
We could also do the rendering in a separate thread, and abandon that
thread if cancel is pressed. That seems more achievable.
We already perform rendering in a separate thread:
https://github.com/openscad/openscad/blob/master/src/cgalworker.cc
While we can abandon this thread, it would still continue to use resources
and block any other CGAL operation until the thread ends. I’m not too
excited about that idea.
I’m not aware of any safe way to kill a thread, but that could be a
worthwhile investigation.
-Marius
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Yes. If you were to kill the thread, then any caching that was done within
CGAL would then be garbage. If there was any local caching, they might be
still valid. Trying to deal with preemptive termination in a thread would
prolly be not worth it as the objects in the library would be in an
indeterminate state. Doing this on a process level would be more cleaner and
more portable.
--
View this message in context: http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20517.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 20. feb. 2017 20:58, Marius Kintel wrote:
I’m not aware of any safe way to kill a thread, but that could be a worthwhile investigation.
I don't know about Qt threads but I have done this with wxWidgets and
boost::threads
One way is to establish a thread safe queue and send messages to the
thread that way (the thread will check the queue). Or 'simply' a mutex
protected variable as was suggested. A third way is to send a message
(wxWidgets has wxThreadEvent, perhaps Qt has something similar... looks
like it https://wiki.qt.io/Threads_Events_QObjects )
Using such techniques it works for any OS or compiler.
Carsten Arnholm
How does that help with a thread that blocks for hours in a library that
you don't control? You either have to kill it asynchronously or wait for it.
On 20 February 2017 at 21:41, Carsten Arnholm arnholm@arnholm.org wrote:
On 20. feb. 2017 20:58, Marius Kintel wrote:
I’m not aware of any safe way to kill a thread, but that could be a
worthwhile investigation.
I don't know about Qt threads but I have done this with wxWidgets and
boost::threads
One way is to establish a thread safe queue and send messages to the
thread that way (the thread will check the queue). Or 'simply' a mutex
protected variable as was suggested. A third way is to send a message
(wxWidgets has wxThreadEvent, perhaps Qt has something similar... looks
like it https://wiki.qt.io/Threads_Events_QObjects )
Using such techniques it works for any OS or compiler.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2017-02-21 01:36, nop head wrote:
How does that help with a thread that blocks for hours in a library
that you don't control? You either have to kill it asynchronously or
wait for it.
If it really blocks for hours without any chance of graceful
termination, I would review the architecture, library or how it is used.
Usually there is a way, e.g. using callbacks, deriving from the thread
class or whatever. Another option is to run lengthy jobs in a separate
process. That is in fact what I do with similar code, and if you
really have to it is easy to kill such processes and I do it
sometimes. The way I understand it, such a setup in OpenSCAD would
require a modified architecture though.
Carsten Arnholm
A multi-process architecture, with rendering in a separate process, is
probably a good solution. It's not just to support "cancel", it is also for
robustness: if the renderer crashes, you don't lose your state. This is how
modern web browsers now work.
On 21 February 2017 at 03:54, arnholm@arnholm.org wrote:
On 2017-02-21 01:36, nop head wrote:
How does that help with a thread that blocks for hours in a library
that you don't control? You either have to kill it asynchronously or
wait for it.
If it really blocks for hours without any chance of graceful termination,
I would review the architecture, library or how it is used. Usually there
is a way, e.g. using callbacks, deriving from the thread class or whatever.
Another option is to run lengthy jobs in a separate process. That is in
fact what I do with similar code, and if you really have to it is easy to
kill such processes and I do it sometimes. The way I understand it, such a
setup in OpenSCAD would require a modified architecture though.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Feb 21, 2017, at 10:07, doug moen doug@moens.org wrote:
A multi-process architecture, with rendering in a separate process, is probably a good solution. It's not just to support "cancel", it is also for robustness: if the renderer crashes, you don't lose your state. This is how modern web browsers now work.
As long as we use CGAL, I think I agree that a separate process is a good way forward. This could also prove to be a way of bypassing the lack of multi-threading in CGAL, at the expense of managing the worker pool, dealing with (de-)serializing and optimizing potential local caching in worker processes.
The question is, as always, if we’re better off spending that time working on alternative CSG engines.
-Marius
And not only for cancel and robustness. Worker processes are also a good
means for parallelizing CGAL calls and speeding up things dramatically on a
contemporary machine. My approach for implementing this would be: Drop the
implicite union of toplevel objects (or add some option for it) and you are
on the way. After rendering top level objects could be checked first by
boundary tests, second by convex hull overlap and third by further CGAL
calls for possible mutual intersection - with most of this work already
being done, while the last CGAL worker process is still running.
kintel wrote
On Feb 21, 2017, at 10:07, doug moen <
doug@
> wrote:
A multi-process architecture, with rendering in a separate process, is
probably a good solution. It's not just to support "cancel", it is also
for robustness: if the renderer crashes, you don't lose your state. This
is how modern web browsers now work.
As long as we use CGAL, I think I agree that a separate process is a good
way forward. This could also prove to be a way of bypassing the lack of
multi-threading in CGAL, at the expense of managing the worker pool,
dealing with (de-)serializing and optimizing potential local caching in
worker processes.
The question is, as always, if we’re better off spending that time working
on alternative CSG engines.
-Marius
OpenSCAD mailing list
Discuss@.openscad
--
View this message in context: http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20538.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Or a separate thread to save the work (like the Arduino IDE, the "Save"
button always works no matter is or is not going on).
Rob
On 20/02/17 15:39, Jerry Davis wrote:
Jon:
I didn't see that. Ok. Option ok. Turn it off by default ok.
Doug:
Didn't know OpenSCAD used a separate lib for CGAL. Separate thread
that is cancellable is better.
--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer
/The most exciting phrase to hear in science - the one that heralds
new discoveries - is not "Eureka!" but "That's funny...".
/- Isaac. Asimov
On Sun, Feb 19, 2017 at 7:12 PM, adrian <adrianh.bsc@gmail.com
mailto:adrianh.bsc@gmail.com> wrote:
Yup. Just an option.
Yes, I do know about AHK. I use it all the time, however, because
the cancel
is broken, the user should be given the option to not start a
render if it
says invoked by accident. And this should be in the program, not as an
external workaround.
--
View this message in context:
http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20502.html
<http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20502.html>
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
<http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website http://www.laketyersbeach.net.au
Ubuntu Mate - A great OS https://ubuntu-mate.org/
Hi, I have just started with OpenSCAD and was looking into this issue with
Amarjeet. After playing around with the code and following along with what
happens upon pressing F6 and the cancel button, I have discovered (or just
implied) that although the slot corresponding to the cancel button on the
progress widget only sets true, the value of bool wascancelled; it is
somehow able to stop proceedings before the function:
evaluator.evaluateGeometry() finishes doing its job.
Once this function actually finishes, then the cancel button does nothing it
seems even on consecutive presses of F6. But if on the first press of F6,
the cancel button is pressed before the evaluator.evaluateGeometry()
function returns from its call, then the process is somehow stopped printing
in accordance to the following catch block in the CGALWorker::work()
function:
catch (const ProgressCancelExcetion &e) {
PRINT("Rendering Cancelled.");
}
My enquiry is that how is this exception generated by a simple assignment of
true to the wascancelled variable in the progressWidget object.
--
Govind Sharma
--
View this message in context: http://forum.openscad.org/Should-have-an-option-to-ask-to-render-when-pressing-F6-tp20486p20725.html
Sent from the OpenSCAD mailing list archive at Nabble.com.