Question: Usage with a concurrent server

[glebm]

I've just started looking into mathcat now and I'm wondering how one would use it from a multi-threaded / concurrent server.

The API seems to consist of global calls, so e.g. if one request calls set_preference with English while another thread does set_preference Spanish, it is unclear what the result would be.

[NSoiffer]

I suppose it was maybe being lazy, but I made MathCAT single threaded since that was easier to do. MathCAT will complete whatever call you make before responding to the next call. You'll need to launch separate copies of MathCAT if you want to do concurrent things.

[glebm]

Oh, I see, that makes it rather unsuitable for our use-case unfortunately. 😓

[NSoiffer]

Thinking about it more, even if I had made MathCAT multithreaded, I don't see how that would have helped your concurrent use case. If you "randomly" call MathCAT with conflicting set_preference calls, what do you expect to happen? It sounds to me like you need to implement some sort of lock mechanism on your server to prevent one thread/process from interfering with what another thread/process is trying to do. Either that, or as I suggested, each thread/process should start up another instance of MathCAT. Or maybe I am misunderstanding what you are trying to do.

[glebm]

I expected preferences to be passed every time or held in an immutable properties object that can be constructed e.g. via MathCAT::new.

Then, in my server, I could construct an instance per language at startup time and dispatch to it.

This would work assuming that no other global mutable state is modified by the calls, as different threads wouldn't write to the same area of memory, at least by methods that borrow a MathCAT object immutably.

The global interface can still stay for users who prefer it for simplicity, backed by a singleton MathCAT object.

[NSoiffer]

MathCAT needs to maintain state because, in the standard use cases, users want to set the preferences, set the MathML, and then query one or more things. In particular, if one is navigating through an expression, it is really useful for MathCAT to hold onto the MathML, the preferences, and the state of where they are in the MathML so they can move relative to where they were and get back braille and speech for the MathML and in the language, etc., they started with.

It would have been possible to make MathCAT stateless, but that would come at the expense of having to set up a lot of state in each call. That makes each call more complicated and much more expensive computationally. In particular, MathCAT spends more time cleaning up MathML when it is set than it spends either generating speech or generating braille. And initializing the rules to generate speech, braille, and navigation takes even more time. When the language, the braille code, or the speech style change, MathCAT needs to re-read the rules for those. Those changes can take 50ms (or as much as 100ms if you are using more obscure Unicode chars). MathCAT stores the preference values used, so subsequent calls that set a preference to a previous value are very cheap (i.e., calling set_preference("Language", "en") over and over is very cheap).

For your case, I suggest your application essentially hold onto the state in terms of what preferences you want to set. Then make calls to MathCAT set them all along with the MathML. Unless time is not an issue, I would try to structure your code so that calls to the same language, speech style, and braille code are bunched together. And of course you need to consider the group of calls as atomic so other threads don't change things while MathCAT is processing the calls. That means you need some sort of lock mechanism around the call(s) to MathCAT.

I'm closing the issue because there really isn't anything actionable that I can do to change MathCAT. Hopefully with the suggestions above, it is not too much work to make your application work with MathCAT.

[glebm]

It would have been possible to make MathCAT stateless, but that would come at the expense of having to set up a lot of state in each call.

In the design I'm proposing, the user can hold on to the state object, so there is no set up in each call.
The global mutable state API can still co-exist (backed by a MathCAT-internal state instance).

[glebm]

A concrete example for Speech (my use case is TTS rather than Braille):

fn load_speech_rules(preferences: &PreferenceManager) -> Result<SpeechRules>

(note that here the PreferenceManager is not the global one but a user-created one)

fn mathml_to_spoken_text(speech_rules: &SpeechRules, mathml: &str) -> Result<String>

In the Speech case, there isn't any mutable state to keep track of.

In the Braille case, an additional mutable state object can be passed along with the rules.

I'll work on a PR as I need it for my purposes, then you can decide whether to take it or not.