> 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
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users