<br><br><div class="gmail_quote">On Feb 5, 2008 12:51 PM, Andreas Raab &lt;<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Terry Raymond wrote:<br>&gt; I think changing the semantics of fork is a way to introduce<br>&gt; a bug to existing code, i.e. one that is aware of the way<br>&gt; fork works and relies on it to work that way.<br>
<br></div>I don&#39;t think you (as well as some of the other posters) really<br>understand what these changes do. To illustrate:<br><br>p1 := p2 := p3 := nil.<br>p1 := [p1Valid := p1 notNil] forkAt: Processor activePriority-1.<br>
p2 := [p2Valid := p2 notNil] forkAt: Processor activePriority.<br>p3 := [p3Valid := p3 notNil] forkAt: Processor activePriority+1.<br><br>Both, the first and the last case are currently deterministic and will<br>stay that way: p1 will be consistently non-nil when this code is run; p3<br>
will be consistently nil when run. This is currently the case and<br>remains the same after applying my changes.<br><br>In the second case however, p2 may or may not be nil, depending on<br>whether external interrupts occur. Since that is rare, in 99.99+% of all<br>
cases p2 will be non-nil.<br><br>What I am proposing is simply to make p2 non-nil in 100% of the cases.<br>There is no change to those parts of the existing semantics that are<br>actually well-defined. The only change is that it takes a rare<br>
non-deterministic occurrence and makes the overall behavior consistent<br>in this case.<br></blockquote></div><br><br>You&#39;re relying on the current implementation of the scheduler. If the implementation of the scheduler changes (such as would happen when Squeak is made capable of using multi-cored or multiple CPUs) then your bug will re-appear and your &quot;fix&quot; will no longer fix the problem 100% of the time.<br>
<br>Process&gt;&gt;fork should fork the process at the same priority as the calling process. Process&gt;&gt;forkAt: should fork the process at the given priority. If they use other priorities than this, then I consider it a bug.<br>
<br>Gulik.<br><br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a>