Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Greenlet – Move an async function into its own thread in the browser

github.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Greenlet – Move an async function into its own thread in the browser

#21

Post by blurspline »

michaelmcmillan wrote: post #6

The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...

after the web worker executes its function, it post a message to the original context with 3 arguments - the call id (c), error string(e), the successful result object(d).

the greenlet function when invoked returns a promise waiting to be resolved or rejected. the resolver and rejector functions are stored in object p with the key with a unique call id.

so line 18 `p[c][e?1:0](e||d);` basically means resolve or reject the promise based on the parameters from the web worker message by invoking either the resolve or reject function stored by its call id.

here's my quick attempt to understand and annotate this lib.

https://gist.github.com/zz85/25564f1910f1877c39c25ace5e5159b...

Re: Greenlet – Move an async function into its own thread in the browser

#22

Post by Moter8 »

developit wrote: post #19
Klathmon wrote: post #7

Earlier quoted context omitted.

It's not just line 18, I barely have any idea what any lines are doing. Single letter variable names are almost always a bad idea except in one case, using `i` as an index, and even then I don't do that any more because `index` is more obvious.

Agreed! There's an open issue to address this - the single letter names are silly, since they get uglified anyway.

Yeah, saw the comment and opened an issue :D

Re: Greenlet – Move an async function into its own thread in the browser

#23

Post by kuschku »

Klathmon wrote: post #17
vog wrote: post #16

Earlier quoted context omitted.

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

I don't know of any offical docs or anything, but I'd imagine it's because it would be a pretty big breaking change. (before babel moved to scoped packages, it would be jarring to see `babel-core` unscoped, but `@babel/babel-plugin-thing` as scoped because it was forced. I also think there is still some roughness around "transferring" scoped packages (what happens when another user takes over a package I authored? do…

All the other package managers have solved that.

Docker and go use URLs/paths for scoping, everything is scoped.

Java/Scala/Kotlin/XText/etc use reversed domains as scope.

And so on.

Re: Greenlet – Move an async function into its own thread in the browser

#24

Post by Klathmon »

untog wrote: post #18
bwindels wrote: post #9

The example could be better chosen. Why execute an action that is already async like fetching a url on a different thread?

JSON parsing (also in the async function) is CPU-heavy, though. If you had a huge, huge amount of JSON it might be worth it. Maybe.

Not in this case, because copying data to and from a web-worker uses "Structured Copy" which is about as fast as JSON unmarshaling, but in this case it's actually doing significantly more work:

* read request

* parse from JSON to an object

* read the data from the object in the worker to the main thread

* create a new object in the main thread with the data from the worker

Those last 2 steps are about as slow as a JSON.stringify and JSON.parse, and are completely unnecessary. As others have said, adding some filtering to the example makes this example worlds better.

Re: Greenlet – Move an async function into its own thread in the browser

#25

Post by Klathmon »

developit wrote: post #20
Klathmon wrote: post #14

Earlier quoted context omitted.

It's single threaded, but with async I/O. That means that any I/O doens't block the main thread, and other parts of JS can execute. This example provides literally no benefits, and actually is a performance hit from converting the data from JSON, then sending it back to the main thread (which itself copies the data in a method similar to converting back to JSON then back to an object again in the main thread).

It's true, the example could be better. However - adding any form of data pruning to the example would immediately show the benefit. JSON parsing happens in the worker, and only a small subset of data is actually serialized and sent back to the main thread.

Yeah, that would be a great way of handling it. The other would be to parse out the data and insert it into the IndexedDB and then in the main thread only pull out what is needed

(I had to do exactly that for a B2B app that was receiving hundreds of MB of data a while back)

Re: Greenlet – Move an async function into its own thread in the browser

#26

Post by Klathmon »

kuschku wrote: post #23
Klathmon wrote: post #17

Earlier quoted context omitted.

I don't know of any offical docs or anything, but I'd imagine it's because it would be a pretty big breaking change. (before babel moved to scoped packages, it would be jarring to see `babel-core` unscoped, but `@babel/babel-plugin-thing` as scoped because it was forced. I also think there is still some roughness around "transferring" scoped packages (what happens when another user takes over a package I authored? do…

All the other package managers have solved that. Docker and go use URLs/paths for scoping, everything is scoped. Java/Scala/Kotlin/XText/etc use reversed domains as scope. And so on.

Yes, but many of them started that way, they didn't have to go through the headache of transferring to that format. And even ecosystems that did go through that trouble, they weren't nearly at the scale that npm is.

We can talk about how awful of an idea it was for npm to start the way they did all we want, but the reality is that they are in the position of unscoped packages being the "default" right now, and I'd love for them to get away from them in a safe manner.

Re: Greenlet – Move an async function into its own thread in the browser

#27

Post by DanHulton »

Klathmon wrote: post #17
vog wrote: post #16

Earlier quoted context omitted.

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

I don't know of any offical docs or anything, but I'd imagine it's because it would be a pretty big breaking change. (before babel moved to scoped packages, it would be jarring to see `babel-core` unscoped, but `@babel/babel-plugin-thing` as scoped because it was forced. I also think there is still some roughness around "transferring" scoped packages (what happens when another user takes over a package I authored? do…

All new packages must be scoped. Existing packages can - and shoudl - be aliased by the owner to a scoped package. Everyone's existing code continues to work, while all new code is safe.

Doesn't seem especially tricky.

Re: Greenlet – Move an async function into its own thread in the browser

#28

Post by Klathmon »

DanHulton wrote: post #27
Klathmon wrote: post #17

Earlier quoted context omitted.

I don't know of any offical docs or anything, but I'd imagine it's because it would be a pretty big breaking change. (before babel moved to scoped packages, it would be jarring to see `babel-core` unscoped, but `@babel/babel-plugin-thing` as scoped because it was forced. I also think there is still some roughness around "transferring" scoped packages (what happens when another user takes over a package I authored? do…

All new packages must be scoped. Existing packages can - and shoudl - be aliased by the owner to a scoped package. Everyone's existing code continues to work, while all new code is safe. Doesn't seem especially tricky.

I agree, but I'm just guessing. I have a feeling that if there weren't any downsides, it would have been done by now.

Re: Greenlet – Move an async function into its own thread in the browser

#29

Post by lhorie »

vog wrote: post #16
Klathmon wrote: post #5

This is off-topic, but at the top of the readme is this: > The name is somewhat of a poor choice, but it was available on npm. npm has supported scoped packages [0] for years now, and it's a fantastic solution to this problem, as well as solving many others (like typosquatting in many cases). I know this package is already named, but I really urge people to use scoped packages more. [0] https://docs.npmjs.com/misc/sc…

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

Would it though? I've noticed a trend of libs being created under orgs of the same name, e.g.

- https://github.com/angular/angular

- https://github.com/rollup/rollup

- https://github.com/cherow/cherow

- https://github.com/hyperapp/hyperapp

Wouldn't we end up with a similar situation?

Re: Greenlet – Move an async function into its own thread in the browser

#30

Post by abjorn »

lhorie wrote: post #29
vog wrote: post #16

Earlier quoted context omitted.

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

Would it though? I've noticed a trend of libs being created under orgs of the same name, e.g. - https://github.com/angular/angular - https://github.com/rollup/rollup - https://github.com/cherow/cherow - https://github.com/hyperapp/hyperapp Wouldn't we end up with a similar situation?

Is that such a bad thing? Slightly redundant, but that seems more aesthetic than anything.
Post reply on HN