Wow, that's a great tip.  I implemented it and long running threads work fine 
and get preempted.

I guess the disadvantage is thread safety and synchronization of data accesses. 
 I'm not clear on when a thread running in v8 might be preempted.  Likely on 
entering or exiting functions (when doing stack checks, I think I remember 
reading about).


On Jul 2, 2012, at 8:03 AM, Pablo Sole wrote:

> You don't seem to be using any context preemption (and you're over a
> single Context) so, what would happen if a thread does a long running
> operation (or may be just a long script) over one Thread? Or may be are
> you thinking on implementing Unlockers for all those kind of operations?
> 
> I'm implementing something around this lines too (for a more specific
> purpose though) and decided to use a diff Isolate per-thread to have
> full parallel execution. Of course in my case I don't need to share much
> information between threads, otherwise it would be impossible to do so.
> 
> Cheers,
> pablo.
> 
> On 07/02/2012 08:46 AM, mschwartz wrote:
>> I was toying with pthreads and V8 and it all pretty much works as I
>> expected.
>> 
>> The repo is here:
>> https://github.com/mschwartz/v8t
>> 
>> It's a pretty small amount of code, so all the v8 API calls used are
>> not so obfuscated.
>> 
>> The test program, test.js is:
>> 
>> var NUM_THREADS = 1000;
>> var nnn = 0;
>> 
>> var pthread = builtin.pthread;
>> 
>> log(pthread);
>> 
>> function Thread(fn) {
>> var args = [];
>> for (var i=1; i<arguments.length; i++) {
>> args.push(arguments[i]);
>> }
>> this.fn = fn;
>> this.args = args;
>> this.t = pthread.spawn(this.run, this);
>> }
>> Thread.prototype.run = function(me) {
>> me.fn.apply(me, me.args);
>> };
>> 
>> function thread(n) {
>> var nnnn = 0;
>> log('thread ' + n);
>> while (true) {
>> nnn++;
>> nnnn++;
>> log('thread ' + this.t + ' here ' + nnn + ' ' + nnnn);
>> }
>> }
>> 
>> function tester(i, n) {
>> log(i + ' ' + n);
>> sleep(n);
>> log('TESTER ' + i + ' EXITING');
>> }
>> 
>> function main() {
>> var threads = [];
>> if (true ) {
>> log('spawning');
>> new Thread(tester, 1, 5);
>> new Thread(tester, 2, 5);
>> new Thread(tester, 3, 6);
>> for (var i=0; i<NUM_THREADS; i++) {
>> threads.push(new Thread(thread, i));
>> }
>> 
>> while (true) {
>> var tid = pthread.wait();
>> log('parent: ' + tid + ' exited');
>> }
>> }
>> else {
>> log('here');
>> }
>> }
>> 
>> A couple of things to note:
>> 
>> First, there is no actual "wait for any thread to exit" kind of
>> functionality in pthreads.  I implemented my own using doubly linked
>> lists and pthread_cond_signal().  pthread_t may be radically different
>> on various operating systems, so I implemented my own threadId scheme,
>> similar to PIDs.
>> 
>> When I spawn 1000 threads, they don't seem to get equal treatment by
>> the scheduler.  Sample output of the test.js program:
>> 81073 thread 514 here 85641 116
>> 81073 thread 713 here 85642 37
>> 81073 thread 712 here 85643 38
>> 81073 thread 711 here 85644 39
>> 81073 thread 710 here 85645 40
>> 81073 thread 709 here 85646 41
>> 81073 thread 515 here 85647 116
>> 81073 thread 516 here 85648 116
>> 81073 thread 517 here 85649 116
>> 81073 thread 518 here 85650 116
>> 81073 thread 519 here 85651 116
>> 81073 thread 520 here 85652 116
>> 81073 thread 521 here 85653 116
>> 81073 thread 522 here 85654 116
>> 81073 thread 523 here 85655 116
>> 81073 thread 524 here 85656 116
>> 81073 thread 525 here 85657 116
>> 81073 thread 526 here 85658 116
>> 81073 thread 527 here 85659 116
>> 81073 thread 528 here 85660 116
>> 81073 thread 529 here 85661 116
>> 81073 thread 635 here 85662 104
>> 81073 thread 634 here 85663 105
>> 81073 thread 530 here 85664 116
>> 81073 thread 531 here 85665 116
>> 81073 thread 680 here 85666 67
>> 81073 thread 679 here 85667 68
>> 81073 thread 678 here 85668 69
>> 81073 thread 532 here 85669 116
>> 81073 thread 533 here 85670 116
>> 81073 thread 741 here 85671 11
>> 81073 thread 740 here 85672 12
>> 81073 thread 739 here 85673 13
>> 
>> As you can see, the first 600 or so threads seem to get equal
>> processor time, while the remaining ones seem really starved for
>> processor time.  I'm not sure if this is due to the OSX pthread
>> scheduler algorithm (I tried all 3 variants, not much difference) or
>> something about how v8::Locker works.
>> 
>> Anyhow, I hope the code is of interest to someone.
>> 
>> -- 
>> v8-users mailing list
>> [email protected]
>> http://groups.google.com/group/v8-users 
> 
> 
> -- 
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to