| | <<<Back 1 day (to 2020/04/06) | Fwd 1 day (to 2020/04/08)>>> | 20200407 |
| kammerer | ator, according to docs "No simultaneous calls to MuPDF in different threads are allowed to use the same context/document". But if such calls are performed from different thread non-simultaneous. Looks like it's allowed. How mupdf synchronizes its state during such execution internally (From Java world I know that without proper synchronization one | 05:33.08 |
| | thread could observe obsole/incomplete/corrupted state that was updated by another one)? | 05:33.08 |
| pink_mist | if you have some way of making sure things are not simultaneous, use that same way of synchronizing? | 05:45.20 |
| kammerer | pink_mist, I can construct next synthetic example (in ideall world): 2 shedulers, that executes rendering task each second (first starts tasks at 1, 2, 3 and second at 1.5, 2.5, 3.5) each task take 0.1 sec, so in ideal world they would be executed non-simultaneous. So what would be with internal state of mupdf engine (would it be consistent). | 06:25.29 |
| | Originally this strange question was arised from GC, as it freeezes all executions and performs all operations in separate thread, destroying for example pages and through them affecting document (and context). | 06:25.29 |
| Robin_Watts_ | kammerer: For the logs. The issue is that the context contains an error stack that is used to implement our exception system. | 12:15.54 |
| | If you have 2 calls into mupdf using the same exception stack at the same time, they will corrupt one another, hence the problem. | 12:16.20 |
| | The issue with the document is that some accesses to the document involve moving the file pointer and reading. If you have 2 threads using the same document at the same time, they can race. | 12:17.50 |
| | It's perfectly fine to make a display list from a page, and then use that in multiple threads at the same time, because that doesn't hit the file. | 12:18.24 |
| kammerer | Robin_Watts_, thanks you for explanation. But one question is still open: what primitives/libraries mupdf uses for internal sycnhronization? I meant is there any garanties that second thread will see consistent data that was updated/constructed by fiirst thread (in suggestion that all operation in non-simultaneous in both threads)? | 17:29.52 |
| | Is it possible to update header of channel because it points to wrong address (url includes . at end). That breaks history loading: hangs on "Loading http://ghostscript.com/mupdfirclogs...." | 17:31.07 |
| | In my question about consistency i assume that mupdf performs at least some caching on read operations | 17:41.21 |
| Robin_Watts_ | kammerer: For the logs. When you init mupdf, you pass in a set of lock/unlock functions. Those provide a set of mutexes (4 if memory serves). | 19:20.19 |
| | MuPDF then locks/unlocks those at appropriate points to ensure that only one thread is in the allocator at a time, etc. | 19:20.48 |
| | We don't do any other sort of synchronisation, because we don't believe we need to. | 19:21.46 |
| | <<<Back 1 day (to 2020/04/06) | Forward 1 day (to 2020/04/08)>>> | |
Log of #mupdf at irc.freenode.net.