Implement memory & thread safe `Cookie`

[monoamine11231]

Why?
Currently, mupdf-rs supports the Cookie struct which is designed to be sent across threads and locked by the inner locks initialized in the main context.

The Cookie struct can be used to abort a current rendering session on another thread by setting the abort flag.

The problem is that the Cookie struct in mupdf-rs is just a wrapper struct holding a raw mut pointer which implements the !Send trait which means that it cannot be used across multiple threads without using unsafe.

[ginnyTheCat]

I've read some mupdf code that uses cookie. What I understand they expect a user to do is set abort = true while the processing function checks again and again whether it is set. From my understanding this is unsound even in C as neither a atomic, mutex or other kind of synchronization is used while two threads read and write to the same shared memory.

If we would allow to do this in Rust we would likely make incomplete a atomic on the rust side to make that sound at least, as otherwise you would be able to call incomplete() and set_incomplete() from two seperate threads and cause unsound behaviour in safe rust code.

Another possible option would be to remove either the incomplete() or set_incomplete() function as then all functions in Cookie would allow to read or write, but no value can both be read and written creating two "one way pipes" between rust and c.

All-in-all this is a quite annoying situation and can't be made safe without patching mupdf (which would for ever prevent us from dynamically linking mupdf in the future) but I think it's worth doing implementing this issue in some way as it is quite a useful feature.

Edit: We should still be able to do dynamic linking as atomics in c don't have a different type. Maybe that even makes it possible to upstream the patch?

[newinnovations]

It is my understanding that all the fields in fz_cookie are one-way, written by one thread and read by the other. Never both, and thus basically safe.

I find it strange that there is a Cookie::set_incomplete() available to the application. I did a quick scan for the incomplete flag and found only references in mupdf setting the flag, but never depending on it to be cleared by the user.

[ginnyTheCat]

Never both, and thus basically safe.

As far as I understand this seems to be mupdf's intention ... but that still makes it unsound even in the C context, which is quite annoying. To do what they intend to, atomics should be used instead.

Edit to my previous comment btw: C11 atomics do hat different types, I was just thinking of the GCC atomic extension which doesn't.