I have now run this for over 48 hours. Recently I started "ping" while it was running and everthing worked just fine for over an hour. Now I am going to try running 3 separate instances of the "try_tcp" script and see how that goes.
Thread: name ( &tp ) state sem pc sp pri Thread: shell (400a7a1c) READY J 40010560 40568000 11 Thread: net-in (400a764c) READY J 40010560 40570000 20 Thread: net-out (400a7558) SEM J net-outq 40010560 40572000 21 Thread: net-slow (400a7464) REPEAT C 40015e68 40574000 22 Thread: tcp-input (400a7834) SEM J tcp-main 40010560 4056c000 24 Thread: tcp-timer (400a7740) REPEAT C 400243ac 4056e000 25 Thread: wangdoodle (400a727c) SEM J socket 40010560 40578000 31 Thread: wang_thr (400a7370) READY J 40010560 40576000 35 * Thread: wang_thr (400a7188) READY I 4001d1d4 4057a000 35 Thread: idle (400a7928) READY C 40010a80 4056a000 1234It works OK, but some of the threads get starved (all the connection handling threads run at priority 35, and Kyu makes no guarantees about how it will handle competing threads at equal priorities.
When all this finishes, I see the Kyu output size claiming to have 2 entries. And when I look at this I catch a signficant oversight, there was no lock around the code where I place entries on the Kyu output queue. So I have fixed this and done a quick test.
Kyu / [email protected]