Closed hansemannn closed 6 years ago
Your changes look fine to me (though I'm not really much of an Obj-C/iOS developer - so I can't really tell if the move from a lock to a queue is correct).
It looks like for iOS you're effectively spinning up a brand new KrollBridge for each worker? So basically we're generating a new VM for it to operate in, and we create a proxy in our original bridge to use to post messages back and forth? This is basically what we had discussed was necessary to be able to do JS background "threads". This obviously has the major caveat that this is an entirely separate VM, so you can't really address objects in the main "thread", but have to resort to passing simple values or objects back and forth to communicate.
The other issue is that of the size of the extra VM and environment. I can't tell how much of the Titanium API we'd be bootstrapping into this new instance, or how much of a RAM hit this may cause. It'd be useful to test it out and see just what this does in terms of memory usage so we can set realistic expectations.
Merging PR as the FT was approved by @Topener today.
Module looks awesome but I cannot seem to find/load worker files. I know my source path is correct but there is no output (when attempting to console.log from worker) & no error message. In fact, the module outputs a successful load even if the source (eg. worker.js
) does not exist. — I'd love to spin up some workers to use but cannot figure out how to actually load them. Any advice?
I did some changes to the module so we can use it for newer iOS- and SDK-versions:
NSRecursiveLock
with serial GCDdispatch_queue_t
terminate()
caused by the replaceterminate
methodTodo: