[Milestone] v1

[jcbhmr]

• Create a basic package template
• Add an implementation of greenlet() #2
• Add an implementation of redlet() #3
• Make them both "work" in Node.js (at least)
• Add benchmarks
• Add tests
• Make sure it works in Deno
• Make sure it works in Bun
• Make sure it works in browsers
• Make it work with transferable objects
• Decide whether or not to capture this too, or just arguments?
• Kill workers after N seconds of no use (not worth it to keep alive?)
• Maybe use SharedWorker if available natively? Probably not, but maybe. Need opinions.
• Support other beyond-JSON serialization for return value of redlet() in browsers

[Aslemammad]

Shall we change the name? @jcbhmr

[jcbhmr]

For the project itself? You can pick whatever name you want! 😊 I couldn't think of anything better than "tinythreadlet" on the spot when I made this thing 🤣

[Aslemammad]

tinylet maybe? it's shorter?

[jcbhmr]

Sounds great! 🚀

[jcbhmr]

Bun doesn't support workers yet. oven-sh/bun#901

[jcbhmr]

@Aslemammad I can't access the Settings menu to add my NPM_TOKEN secret. Would you like to handle that, or how should I go about doing that? I've invited you on npmjs.com to be a "Maintainer" of the package:

[jcbhmr]

Heyyyy @jimmywarting! I notice you also made something similar to the redlet() function that I have in here. https://github.com/jimmywarting/await-sync

If @Aslemammad is willing (I don't have access to the Settings tab) I think it'd be great to add you as a "collaborator" or whatever it's called (you don't have to though ❤️) since you seem to know a thing-or-two about worker sync SharedArrayBuffer magic. 😊

[Aslemammad]

@jcbhmr I changed your access, try again now.

[Aslemammad]

I'm ok with adding Jimmy to the collaborators, in fact, I'd be happy.

[jcbhmr]

👍 Added granular NPM_TOKEN 300 day expiry perms to read/write "tinylet" package only

[jimmywarting]

Hi, yes my await-sync pkg dose similar thing to redlet()

I'm only going to comment on redlet() and give some feedback cuz that's what i kind of have built...

---

One key differences are that mine dose only allocated a fixed amount of SharedArrayBuffer and dose a little dance back and forth to kind of stream the data over to the other thread (sync) instead of using the grow method. (my tough was to be more memory friendly) so the receiver (caller) allocated a fixed amount of Uint8Array and the worker "writes" to it chunk-by-chunk.
Mine also don't assume any specific serialization which is left onto the developer in order to support other stuff.

const buf2text = TextDecoder.prototype.decode.bind(new TextDecoder)
const deserialize = uint8 => JSON.parse(buf2text(uint8))

const get = awaitSync(async url => {
	const res = await fetch(url)
  const text = await res.arrayBuffer()

  return new Uint8Array(text) // Must always return a Uint8Array
}, deserialize) // Optional deserialize function here as 2nd argument, otherwise it returns uint8arr

const json = get('https://httpbin.org/get') // JSON

I found this:

const f = redlet(async (u) => {
  const response = await fetch(u);
  return await response.json();
})

to be redundant to have to parse the response from uint8array -> text -> object -> text -> uint8array in the worker when it can just be passed over in a more direct approach instead. On the plus side it's more ergonomic. on the bad side it's less versatile to support other non-json stuff like a protobuf or file content or any kind of binary.

Make it work with transferable objects
This is going to be tuff depending on what you mean by this...

if it's about transferring functions argument then that is a peace of cake. for the return body it will be harder.

the only thing that is going to support being transferable are the functions argument when you send a postMessage and order the worker to do work... they can be transfered over. but in get something that's a transferable object back from a return statement in a sync manner would be to use the NodeJS specific receiveMessageOnPort but that's not going to work outside of NodeJS. the only way to transfer something synchronous over worker threads is to use sharedArrayBuffer as you might have already guessed by now... for this reasons i recommend using cbor-x to be able to (de)serialize it back and forth...