Bug in scheduler

[krestenkrab]

java.util.NoSuchElementException
at java.util.LinkedList.remove(LinkedList.java:788)
at java.util.LinkedList.removeFirst(LinkedList.java:134)
at java.util.LinkedList.poll(LinkedList.java:470)
at kilim.Scheduler.schedule(Scheduler.java:67)
at kilim.Task.resume(Task.java:203)
at kilim.Task._runExecute(Task.java:448)
at kilim.WorkerThread.run(WorkerThread.java:47)
[java] exiting <0.0.4> with: java.util.NoSuchElementException
<0.0.4>4(running=true,pr=null)::erlang:apply/2
at java.util.LinkedList.remove(LinkedList.java:788)
at java.util.LinkedList.removeFirst(LinkedList.java:134)
at java.util.LinkedList.poll(LinkedList.java:470)
at kilim.Scheduler.schedule(Scheduler.java:67)
at kilim.Task.resume(Task.java:203)
at kilim.Task.messageAvailable(Task.java:178)
at kilim.Mailbox.put(Mailbox.java:318)
at kilim.Mailbox.put(Mailbox.java:411)
at erjang.driver.EDriverTask.close(EDriverTask.java:574)
at erjang.EInternalPort.close(EInternalPort.java:181)
at erjang.m.erlang.ErlPort.port_close(ErlPort.java:354)
at erjang.m.prim_file.prim_file.drv_close__1(prim_file.S:219)
at erjang.m.prim_file.prim_file$FN_drv_close__1.go(Unknown Source)
at erjang.m.prim_file.prim_file.close__1$call(prim_file.S)
at erjang.m.prim_file.prim_file.read_file__1(prim_file.S:96)
at erjang.m.prim_file.prim_file$FN_read_file__1.invoke(Unknown Source)

[eriksoe]

kilim.Scheduler's constructor is not written in a way conformant with the Java memory model (i.e., in a way guaranteed not to give problems).
This includes, but is not limited to, problems when Scheduler is derived from.
The problem is that the constructor "leaks" self - it makes 'this' be available (to other threads) before the Scheduler object has been completely constructed.
(Note that this problem would go away if the constructor refrained from starting the worker threads; creating the Thread objects in itself is not a problem.)

[eriksoe]

Looking at the Scheduler source code, I think the following two changes should be enough to make 'waitingThreads' be handled in a guaranteed thread-safe manner are:

• Prevent the constructor from starting its worker threads
• Make waitingThreads be final.

Possibly, it would be enough to

• Make the constructor work in two passes: First populate 'waitingThreads', then start all the worker threads.