Is OJ actually sync or async?

[IngwiePhoenix]

While experimenting with a variety of modules lately, I actually wondered: Is OJ sync?

Parsing a file into an AST sounds synchronous to me, and transforming it, too.

So is OJ actually sync but uses the callback-style signature for consistency or is there another reason for that?

Kind regards, the curios me. :)

[iccir]

A lot of the compilation process is sync (parsing and transforming); however, there are async parts, like the hinter or typechecker.

[IngwiePhoenix]

I see. Though, the typechecker is optional, and the hinter?

Out of curiosity, is there actually a way to make OJ become a sync compiler?

2015-10-08 2:00 GMT+02:00 Ricci Adams notifications@github.com:

A lot of the compilation process is sync (parsing and transforming); however, there are async parts, like the hinter or typechecker.

— Reply to this email directly or view it on GitHub https://github.com/musictheory/oj/issues/61#issuecomment-146370707.

[iccir]

Unlikely - if it's sync, I have to make sure that every dependency in oj also provides sync versions. This is also one of my longstanding gripes with node - there are situations when you want sync behavior (for example, writing a simple shell tool) and node tends to have a "it's async all the way down!" approach. In my ideal world, you could wrap an async function or Promise with a "make this synchronous" wrapper for the rare applications where it makes sense. Unfortunately, I'm pretty sure that people would abuse this and it would result in real-world "Why is my server no longer accepting requests?" scenarios.

[IngwiePhoenix]

Well I did wrap OJ in deasync for a little tool to make it sync. But weirdly, when using deasync, overall performance seems to be pretty horrible. That is the reason why I asked. Because soemthing tells me that my async-to-sync wrapper is causing more commotion than usability.

Well it will work for me for now, since its just a tiny tool. But if you get aroudn to making OJ behave sync, that would be very interesting!

[iccir]

I don't think that's going to happen, unless there is a major shift in the node ecosystem (and I suspect such a shift would be from callbacks to Promises/Generators/async-await rather than from async->sync).

Based on a 30 second read of deasync, I'm not surprised it's killing performance - it's spinning up the run loop from the JS side, and calling several JS functions for each spin. It'd probably be more efficient to have all the spinning/checking logic from the C++ side. But I don't know the details of V8.

[IngwiePhoenix]

V8 has a nice API, but coding complex things in it is rather...well, awkward. It's why NodeJS has more than half of their code base written in JS and serialized into C++ strings, which are passed to V8 for pre-execution.

But deasync still seems to be less optimized than I thought after reading the code myself. Oh well, it serves the purpose, I guess...

[iccir]

The issue with V8 is that the API is always in flux, hence the existence of nan. I'm guessing that some kind of desync in C++ would need to use raw V8 internals, and would likely break often.