cancellation of booleans

[wtholliday]

I would like to add cancellation of boolean operations to the library. Am I correct that no facility currently exists? Progress reporting would be nice as well, though my primary concern is that I'm throwing big enough meshes at Manifold that iOS tends to kill my app for using too much memory. With a cancellation callback I could (hopefully) react to the OS memory warning in time and cancel the operation.

@elalish @pca006132 can you provide guidance? Is the boolean operation done lazily so an optional callback could be passed to Manifold::GetMeshGL()?

thanks!

[pca006132]

Cancellation is hard, we can probably add some checkpoints, but a lot of changes will have to be done.

I'm thinking about a simpler but hacky way: record the memory used by our Vec by calling some user provided callback (global one...) during each resize event, and allow the user to just abort the allocation request and throw an exception to cancel the whole operation. Cleanup should not be too hard. Ideally, this can allow you to stop the thing before getting OS memory warning, because sometimes it can immediately OOM...

[pca006132]

It feels like a hack because I don't like global stuff :), but yeah it is probably the best way to do it.

Thread local will not work, we may run things in parallel so part of the code can execute in another thread.

[wtholliday]

Well surely TBB has cancellation facilities and within a job you can use a thread-local to avoid having to pass the cancellation function all over the place (or maybe TBB, etc. has made that easier).

[pca006132]

It is not this simple. We have other more time consuming tasks apart from things running tbb tasks. Even when an algorithm is cancelled in tbb, it has to wait for the current work unit to finish, which may still take a long time (and doesn't guarantee we will not request for more memory).

We have nested parallelism, so thread local will not be very useful for us, we still have to add code that passes the cancellation function to subtasks or do some global variable thing. I think for typical applications, using global variable for this should be fine.

Also, my proposal isn't really cancellation, but a memory limit (approximately). It cannot guarantee fast cancellation without adding code in some of the sequential loops that check for global flags. It can only stop the execution when the task attempts further allocation, and tbb will cancel pending tasks when there is an exception. It is approximate because we can only count memory usage in our custom vector implementation, memory usage by stl containers for example are invisible to this.

For your usecase though, I think such memory limit is probably better than a cancellation mechanism?

[wtholliday]

I think I may need both really. If an app is serious about being user friendly, any long-running task needs to be cancellable.

I've had some experience with adding cancellation to other nontrivial things, so maybe I'll just give it a try and see how far I get :)

[pca006132]

Yeah, feel free to give it a try. For other projects, they may be able to get away with using subprocess to make things cancellable, but that is probably not possible with apps.

I would expect the above-mentioned changes to vec, as well as adding some checks to some of our time-consuming sequential parts?

[pca006132]

@kintel you may be interested in this as well.