blob: b7860c6d711b4b7d1dc2efba4c266c22752d8fff [file] [log] [blame]
<HTML>
<BODY BGCOLOR="white">
<PRE>
<FONT color="green">001</FONT> /*<a name="line.1"></a>
<FONT color="green">002</FONT> * Licensed to the Apache Software Foundation (ASF) under one<a name="line.2"></a>
<FONT color="green">003</FONT> * or more contributor license agreements. See the NOTICE file<a name="line.3"></a>
<FONT color="green">004</FONT> * distributed with this work for additional information<a name="line.4"></a>
<FONT color="green">005</FONT> * regarding copyright ownership. The ASF licenses this file<a name="line.5"></a>
<FONT color="green">006</FONT> * to you under the Apache License, Version 2.0 (the "License");<a name="line.6"></a>
<FONT color="green">007</FONT> * you may not use this file except in compliance with the License.<a name="line.7"></a>
<FONT color="green">008</FONT> * You may obtain a copy of the License at<a name="line.8"></a>
<FONT color="green">009</FONT> *<a name="line.9"></a>
<FONT color="green">010</FONT> * http://www.apache.org/licenses/LICENSE-2.0<a name="line.10"></a>
<FONT color="green">011</FONT> *<a name="line.11"></a>
<FONT color="green">012</FONT> * Unless required by applicable law or agreed to in writing, software<a name="line.12"></a>
<FONT color="green">013</FONT> * distributed under the License is distributed on an "AS IS" BASIS,<a name="line.13"></a>
<FONT color="green">014</FONT> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.<a name="line.14"></a>
<FONT color="green">015</FONT> * See the License for the specific language governing permissions and<a name="line.15"></a>
<FONT color="green">016</FONT> * limitations under the License.<a name="line.16"></a>
<FONT color="green">017</FONT> */<a name="line.17"></a>
<FONT color="green">018</FONT> /*<a name="line.18"></a>
<FONT color="green">019</FONT> * $Id: CoroutineManager.java 468653 2006-10-28 07:07:05Z minchau $<a name="line.19"></a>
<FONT color="green">020</FONT> */<a name="line.20"></a>
<FONT color="green">021</FONT> package org.apache.xml.dtm.ref;<a name="line.21"></a>
<FONT color="green">022</FONT> <a name="line.22"></a>
<FONT color="green">023</FONT> import java.util.BitSet;<a name="line.23"></a>
<FONT color="green">024</FONT> <a name="line.24"></a>
<FONT color="green">025</FONT> import org.apache.xml.res.XMLErrorResources;<a name="line.25"></a>
<FONT color="green">026</FONT> import org.apache.xml.res.XMLMessages;<a name="line.26"></a>
<FONT color="green">027</FONT> <a name="line.27"></a>
<FONT color="green">028</FONT> <a name="line.28"></a>
<FONT color="green">029</FONT> /**<a name="line.29"></a>
<FONT color="green">030</FONT> * &lt;p&gt;Support the coroutine design pattern.&lt;/p&gt;<a name="line.30"></a>
<FONT color="green">031</FONT> * <a name="line.31"></a>
<FONT color="green">032</FONT> * &lt;p&gt;A coroutine set is a very simple cooperative non-preemptive<a name="line.32"></a>
<FONT color="green">033</FONT> * multitasking model, where the switch from one task to another is<a name="line.33"></a>
<FONT color="green">034</FONT> * performed via an explicit request. Coroutines interact according to<a name="line.34"></a>
<FONT color="green">035</FONT> * the following rules:&lt;/p&gt;<a name="line.35"></a>
<FONT color="green">036</FONT> *<a name="line.36"></a>
<FONT color="green">037</FONT> * &lt;ul&gt;<a name="line.37"></a>
<FONT color="green">038</FONT> * &lt;li&gt;One coroutine in the set has control, which it retains until it<a name="line.38"></a>
<FONT color="green">039</FONT> * either exits or resumes another coroutine.&lt;/li&gt;<a name="line.39"></a>
<FONT color="green">040</FONT> * &lt;li&gt;A coroutine is activated when it is resumed by some other coroutine<a name="line.40"></a>
<FONT color="green">041</FONT> * for the first time.&lt;/li&gt;<a name="line.41"></a>
<FONT color="green">042</FONT> * &lt;li&gt;An active coroutine that gives up control by resuming another in<a name="line.42"></a>
<FONT color="green">043</FONT> * the set retains its context -- including call stack and local variables<a name="line.43"></a>
<FONT color="green">044</FONT> * -- so that if/when it is resumed, it will proceed from the point at which<a name="line.44"></a>
<FONT color="green">045</FONT> * it last gave up control.&lt;/li&gt;<a name="line.45"></a>
<FONT color="green">046</FONT> * &lt;/ul&gt;<a name="line.46"></a>
<FONT color="green">047</FONT> *<a name="line.47"></a>
<FONT color="green">048</FONT> * &lt;p&gt;Coroutines can be thought of as falling somewhere between pipes and<a name="line.48"></a>
<FONT color="green">049</FONT> * subroutines. Like call/return, there is an explicit flow of control<a name="line.49"></a>
<FONT color="green">050</FONT> * from one coroutine to another. Like pipes, neither coroutine is<a name="line.50"></a>
<FONT color="green">051</FONT> * actually "in charge", and neither must exit in order to transfer<a name="line.51"></a>
<FONT color="green">052</FONT> * control to the other. &lt;/p&gt;<a name="line.52"></a>
<FONT color="green">053</FONT> * <a name="line.53"></a>
<FONT color="green">054</FONT> * &lt;p&gt;One classic application of coroutines is in compilers, where both<a name="line.54"></a>
<FONT color="green">055</FONT> * the parser and the lexer are maintaining complex state<a name="line.55"></a>
<FONT color="green">056</FONT> * information. The parser resumes the lexer to process incoming<a name="line.56"></a>
<FONT color="green">057</FONT> * characters into lexical tokens, and the lexer resumes the parser<a name="line.57"></a>
<FONT color="green">058</FONT> * when it has reached a point at which it has a reliably interpreted<a name="line.58"></a>
<FONT color="green">059</FONT> * set of tokens available for semantic processing. Structuring this<a name="line.59"></a>
<FONT color="green">060</FONT> * as call-and-return would require saving and restoring a<a name="line.60"></a>
<FONT color="green">061</FONT> * considerable amount of state each time. Structuring it as two tasks<a name="line.61"></a>
<FONT color="green">062</FONT> * connected by a queue may involve higher overhead (in systems which<a name="line.62"></a>
<FONT color="green">063</FONT> * can optimize the coroutine metaphor), isn't necessarily as clear in<a name="line.63"></a>
<FONT color="green">064</FONT> * intent, may have trouble handling cases where data flows in both<a name="line.64"></a>
<FONT color="green">065</FONT> * directions, and may not handle some of the more complex cases where<a name="line.65"></a>
<FONT color="green">066</FONT> * more than two coroutines are involved.&lt;/p&gt;<a name="line.66"></a>
<FONT color="green">067</FONT> * <a name="line.67"></a>
<FONT color="green">068</FONT> * &lt;p&gt;Most coroutine systems also provide a way to pass data between the<a name="line.68"></a>
<FONT color="green">069</FONT> * source and target of a resume operation; this is sometimes referred<a name="line.69"></a>
<FONT color="green">070</FONT> * to as "yielding" a value. Others rely on the fact that, since only<a name="line.70"></a>
<FONT color="green">071</FONT> * one member of a coroutine set is running at a time and does not<a name="line.71"></a>
<FONT color="green">072</FONT> * lose control until it chooses to do so, data structures may be<a name="line.72"></a>
<FONT color="green">073</FONT> * directly shared between them with only minimal precautions.&lt;/p&gt;<a name="line.73"></a>
<FONT color="green">074</FONT> * <a name="line.74"></a>
<FONT color="green">075</FONT> * &lt;p&gt;"Note: This should not be taken to mean that producer/consumer<a name="line.75"></a>
<FONT color="green">076</FONT> * problems should be always be done with coroutines." Queueing is<a name="line.76"></a>
<FONT color="green">077</FONT> * often a better solution when only two threads of execution are<a name="line.77"></a>
<FONT color="green">078</FONT> * involved and full two-way handshaking is not required. It's a bit<a name="line.78"></a>
<FONT color="green">079</FONT> * difficult to find short pedagogical examples that require<a name="line.79"></a>
<FONT color="green">080</FONT> * coroutines for a clear solution.&lt;/p&gt;<a name="line.80"></a>
<FONT color="green">081</FONT> * <a name="line.81"></a>
<FONT color="green">082</FONT> * &lt;p&gt;The fact that only one of a group of coroutines is running at a<a name="line.82"></a>
<FONT color="green">083</FONT> * time, and the control transfer between them is explicit, simplifies<a name="line.83"></a>
<FONT color="green">084</FONT> * their possible interactions, and in some implementations permits<a name="line.84"></a>
<FONT color="green">085</FONT> * them to be implemented more efficiently than general multitasking.<a name="line.85"></a>
<FONT color="green">086</FONT> * In some situations, coroutines can be compiled out entirely;<a name="line.86"></a>
<FONT color="green">087</FONT> * in others, they may only require a few instructions more than a<a name="line.87"></a>
<FONT color="green">088</FONT> * simple function call.&lt;/p&gt;<a name="line.88"></a>
<FONT color="green">089</FONT> *<a name="line.89"></a>
<FONT color="green">090</FONT> * &lt;p&gt;This version is built on top of standard Java threading, since<a name="line.90"></a>
<FONT color="green">091</FONT> * that's all we have available right now. It's been encapsulated for<a name="line.91"></a>
<FONT color="green">092</FONT> * code clarity and possible future optimization.&lt;/p&gt;<a name="line.92"></a>
<FONT color="green">093</FONT> * <a name="line.93"></a>
<FONT color="green">094</FONT> * &lt;p&gt;(Two possible approaches: wait-notify based and queue-based. Some<a name="line.94"></a>
<FONT color="green">095</FONT> * folks think that a one-item queue is a cleaner solution because it's<a name="line.95"></a>
<FONT color="green">096</FONT> * more abstract -- but since coroutine _is_ an abstraction I'm not really<a name="line.96"></a>
<FONT color="green">097</FONT> * worried about that; folks should be able to switch this code without<a name="line.97"></a>
<FONT color="green">098</FONT> * concern.)&lt;/p&gt;<a name="line.98"></a>
<FONT color="green">099</FONT> * <a name="line.99"></a>
<FONT color="green">100</FONT> * &lt;p&gt;%TBD% THIS SHOULD BE AN INTERFACE, to facilitate building other<a name="line.100"></a>
<FONT color="green">101</FONT> * implementations... perhaps including a true coroutine system<a name="line.101"></a>
<FONT color="green">102</FONT> * someday, rather than controlled threading. Arguably Coroutine<a name="line.102"></a>
<FONT color="green">103</FONT> * itself should be an interface much like Runnable, but I think that<a name="line.103"></a>
<FONT color="green">104</FONT> * can be built on top of this.&lt;/p&gt;<a name="line.104"></a>
<FONT color="green">105</FONT> * */<a name="line.105"></a>
<FONT color="green">106</FONT> public class CoroutineManager<a name="line.106"></a>
<FONT color="green">107</FONT> {<a name="line.107"></a>
<FONT color="green">108</FONT> /** "Is this coroutine ID number already in use" lookup table.<a name="line.108"></a>
<FONT color="green">109</FONT> * Currently implemented as a bitset as a compromise between<a name="line.109"></a>
<FONT color="green">110</FONT> * compactness and speed of access, but obviously other solutions<a name="line.110"></a>
<FONT color="green">111</FONT> * could be applied.<a name="line.111"></a>
<FONT color="green">112</FONT> * */<a name="line.112"></a>
<FONT color="green">113</FONT> BitSet m_activeIDs=new BitSet();<a name="line.113"></a>
<FONT color="green">114</FONT> <a name="line.114"></a>
<FONT color="green">115</FONT> /** Limit on the coroutine ID numbers accepted. I didn't want the<a name="line.115"></a>
<FONT color="green">116</FONT> * in-use table to grow without bound. If we switch to a more efficient<a name="line.116"></a>
<FONT color="green">117</FONT> * sparse-array mechanism, it may be possible to raise or eliminate<a name="line.117"></a>
<FONT color="green">118</FONT> * this boundary.<a name="line.118"></a>
<FONT color="green">119</FONT> * @xsl.usage internal<a name="line.119"></a>
<FONT color="green">120</FONT> */<a name="line.120"></a>
<FONT color="green">121</FONT> static final int m_unreasonableId=1024;<a name="line.121"></a>
<FONT color="green">122</FONT> <a name="line.122"></a>
<FONT color="green">123</FONT> /** Internal field used to hold the data being explicitly passed<a name="line.123"></a>
<FONT color="green">124</FONT> * from one coroutine to another during a co_resume() operation.<a name="line.124"></a>
<FONT color="green">125</FONT> * (Of course implicit data sharing may also occur; one of the reasons<a name="line.125"></a>
<FONT color="green">126</FONT> * for using coroutines is that you're guaranteed that none of the<a name="line.126"></a>
<FONT color="green">127</FONT> * other coroutines in your set are using shared structures at the time<a name="line.127"></a>
<FONT color="green">128</FONT> * you access them.)<a name="line.128"></a>
<FONT color="green">129</FONT> *<a name="line.129"></a>
<FONT color="green">130</FONT> * %REVIEW% It's been proposed that we be able to pass types of data<a name="line.130"></a>
<FONT color="green">131</FONT> * other than Object -- more specific object types, or<a name="line.131"></a>
<FONT color="green">132</FONT> * lighter-weight primitives. This would seem to create a potential<a name="line.132"></a>
<FONT color="green">133</FONT> * explosion of "pass x recieve y back" methods (or require<a name="line.133"></a>
<FONT color="green">134</FONT> * fracturing resume into two calls, resume-other and<a name="line.134"></a>
<FONT color="green">135</FONT> * wait-to-be-resumed), and the weight issue could be managed by<a name="line.135"></a>
<FONT color="green">136</FONT> * reusing a mutable buffer object to contain the primitive<a name="line.136"></a>
<FONT color="green">137</FONT> * (remember that only one coroutine runs at a time, so once the<a name="line.137"></a>
<FONT color="green">138</FONT> * buffer's set it won't be walked on). Typechecking objects is<a name="line.138"></a>
<FONT color="green">139</FONT> * interesting from a code-robustness point of view, but it's<a name="line.139"></a>
<FONT color="green">140</FONT> * unclear whether it makes sense to encapsulate that in the<a name="line.140"></a>
<FONT color="green">141</FONT> * coroutine code or let the callers do it, since it depends on RTTI<a name="line.141"></a>
<FONT color="green">142</FONT> * either way. Restricting the parameters to objects implementing a<a name="line.142"></a>
<FONT color="green">143</FONT> * specific CoroutineParameter interface does _not_ seem to be a net<a name="line.143"></a>
<FONT color="green">144</FONT> * win; applications can do so if they want via front-end code, but<a name="line.144"></a>
<FONT color="green">145</FONT> * there seem to be too many use cases involving passing an existing<a name="line.145"></a>
<FONT color="green">146</FONT> * object type that you may not have the freedom to alter and may<a name="line.146"></a>
<FONT color="green">147</FONT> * not want to spend time wrapping another object around.<a name="line.147"></a>
<FONT color="green">148</FONT> * */<a name="line.148"></a>
<FONT color="green">149</FONT> Object m_yield=null;<a name="line.149"></a>
<FONT color="green">150</FONT> <a name="line.150"></a>
<FONT color="green">151</FONT> // Expose???<a name="line.151"></a>
<FONT color="green">152</FONT> final static int NOBODY=-1;<a name="line.152"></a>
<FONT color="green">153</FONT> final static int ANYBODY=-1;<a name="line.153"></a>
<FONT color="green">154</FONT> <a name="line.154"></a>
<FONT color="green">155</FONT> /** Internal field used to confirm that the coroutine now waking up is<a name="line.155"></a>
<FONT color="green">156</FONT> * in fact the one we intended to resume. Some such selection mechanism<a name="line.156"></a>
<FONT color="green">157</FONT> * is needed when more that two coroutines are operating within the same<a name="line.157"></a>
<FONT color="green">158</FONT> * group.<a name="line.158"></a>
<FONT color="green">159</FONT> */<a name="line.159"></a>
<FONT color="green">160</FONT> int m_nextCoroutine=NOBODY;<a name="line.160"></a>
<FONT color="green">161</FONT> <a name="line.161"></a>
<FONT color="green">162</FONT> /** &lt;p&gt;Each coroutine in the set managed by a single<a name="line.162"></a>
<FONT color="green">163</FONT> * CoroutineManager is identified by a small positive integer. This<a name="line.163"></a>
<FONT color="green">164</FONT> * brings up the question of how to manage those integers to avoid<a name="line.164"></a>
<FONT color="green">165</FONT> * reuse... since if two coroutines use the same ID number, resuming<a name="line.165"></a>
<FONT color="green">166</FONT> * that ID could resume either. I can see arguments for either<a name="line.166"></a>
<FONT color="green">167</FONT> * allowing applications to select their own numbers (they may want<a name="line.167"></a>
<FONT color="green">168</FONT> * to declare mnemonics via manefest constants) or generating<a name="line.168"></a>
<FONT color="green">169</FONT> * numbers on demand. This routine's intended to support both<a name="line.169"></a>
<FONT color="green">170</FONT> * approaches.&lt;/p&gt;<a name="line.170"></a>
<FONT color="green">171</FONT> *<a name="line.171"></a>
<FONT color="green">172</FONT> * &lt;p&gt;%REVIEW% We could use an object as the identifier. Not sure<a name="line.172"></a>
<FONT color="green">173</FONT> * it's a net gain, though it would allow the thread to be its own<a name="line.173"></a>
<FONT color="green">174</FONT> * ID. Ponder.&lt;/p&gt;<a name="line.174"></a>
<FONT color="green">175</FONT> *<a name="line.175"></a>
<FONT color="green">176</FONT> * @param coroutineID If &gt;=0, requests that we reserve this number.<a name="line.176"></a>
<FONT color="green">177</FONT> * If &lt;0, requests that we find, reserve, and return an available ID<a name="line.177"></a>
<FONT color="green">178</FONT> * number.<a name="line.178"></a>
<FONT color="green">179</FONT> *<a name="line.179"></a>
<FONT color="green">180</FONT> * @return If &gt;=0, the ID number to be used by this coroutine. If &lt;0,<a name="line.180"></a>
<FONT color="green">181</FONT> * an error occurred -- the ID requested was already in use, or we<a name="line.181"></a>
<FONT color="green">182</FONT> * couldn't assign one without going over the "unreasonable value" mark<a name="line.182"></a>
<FONT color="green">183</FONT> * */<a name="line.183"></a>
<FONT color="green">184</FONT> public synchronized int co_joinCoroutineSet(int coroutineID)<a name="line.184"></a>
<FONT color="green">185</FONT> {<a name="line.185"></a>
<FONT color="green">186</FONT> if(coroutineID&gt;=0)<a name="line.186"></a>
<FONT color="green">187</FONT> {<a name="line.187"></a>
<FONT color="green">188</FONT> if(coroutineID&gt;=m_unreasonableId || m_activeIDs.get(coroutineID))<a name="line.188"></a>
<FONT color="green">189</FONT> return -1;<a name="line.189"></a>
<FONT color="green">190</FONT> }<a name="line.190"></a>
<FONT color="green">191</FONT> else<a name="line.191"></a>
<FONT color="green">192</FONT> {<a name="line.192"></a>
<FONT color="green">193</FONT> // What I want is "Find first clear bit". That doesn't exist.<a name="line.193"></a>
<FONT color="green">194</FONT> // JDK1.2 added "find last set bit", but that doesn't help now.<a name="line.194"></a>
<FONT color="green">195</FONT> coroutineID=0;<a name="line.195"></a>
<FONT color="green">196</FONT> while(coroutineID&lt;m_unreasonableId)<a name="line.196"></a>
<FONT color="green">197</FONT> {<a name="line.197"></a>
<FONT color="green">198</FONT> if(m_activeIDs.get(coroutineID))<a name="line.198"></a>
<FONT color="green">199</FONT> ++coroutineID;<a name="line.199"></a>
<FONT color="green">200</FONT> else<a name="line.200"></a>
<FONT color="green">201</FONT> break;<a name="line.201"></a>
<FONT color="green">202</FONT> }<a name="line.202"></a>
<FONT color="green">203</FONT> if(coroutineID&gt;=m_unreasonableId)<a name="line.203"></a>
<FONT color="green">204</FONT> return -1;<a name="line.204"></a>
<FONT color="green">205</FONT> }<a name="line.205"></a>
<FONT color="green">206</FONT> <a name="line.206"></a>
<FONT color="green">207</FONT> m_activeIDs.set(coroutineID);<a name="line.207"></a>
<FONT color="green">208</FONT> return coroutineID;<a name="line.208"></a>
<FONT color="green">209</FONT> }<a name="line.209"></a>
<FONT color="green">210</FONT> <a name="line.210"></a>
<FONT color="green">211</FONT> /** In the standard coroutine architecture, coroutines are<a name="line.211"></a>
<FONT color="green">212</FONT> * identified by their method names and are launched and run up to<a name="line.212"></a>
<FONT color="green">213</FONT> * their first yield by simply resuming them; its's presumed that<a name="line.213"></a>
<FONT color="green">214</FONT> * this recognizes the not-already-running case and does the right<a name="line.214"></a>
<FONT color="green">215</FONT> * thing. We seem to need a way to achieve that same threadsafe<a name="line.215"></a>
<FONT color="green">216</FONT> * run-up... eg, start the coroutine with a wait.<a name="line.216"></a>
<FONT color="green">217</FONT> *<a name="line.217"></a>
<FONT color="green">218</FONT> * %TBD% whether this makes any sense...<a name="line.218"></a>
<FONT color="green">219</FONT> *<a name="line.219"></a>
<FONT color="green">220</FONT> * @param thisCoroutine the identifier of this coroutine, so we can<a name="line.220"></a>
<FONT color="green">221</FONT> * recognize when we are being resumed.<a name="line.221"></a>
<FONT color="green">222</FONT> * @exception java.lang.NoSuchMethodException if thisCoroutine isn't<a name="line.222"></a>
<FONT color="green">223</FONT> * a registered member of this group. %REVIEW% whether this is the<a name="line.223"></a>
<FONT color="green">224</FONT> * best choice.<a name="line.224"></a>
<FONT color="green">225</FONT> * */<a name="line.225"></a>
<FONT color="green">226</FONT> public synchronized Object co_entry_pause(int thisCoroutine) throws java.lang.NoSuchMethodException<a name="line.226"></a>
<FONT color="green">227</FONT> {<a name="line.227"></a>
<FONT color="green">228</FONT> if(!m_activeIDs.get(thisCoroutine))<a name="line.228"></a>
<FONT color="green">229</FONT> throw new java.lang.NoSuchMethodException();<a name="line.229"></a>
<FONT color="green">230</FONT> <a name="line.230"></a>
<FONT color="green">231</FONT> while(m_nextCoroutine != thisCoroutine)<a name="line.231"></a>
<FONT color="green">232</FONT> {<a name="line.232"></a>
<FONT color="green">233</FONT> try <a name="line.233"></a>
<FONT color="green">234</FONT> {<a name="line.234"></a>
<FONT color="green">235</FONT> wait();<a name="line.235"></a>
<FONT color="green">236</FONT> }<a name="line.236"></a>
<FONT color="green">237</FONT> catch(java.lang.InterruptedException e)<a name="line.237"></a>
<FONT color="green">238</FONT> {<a name="line.238"></a>
<FONT color="green">239</FONT> // %TBD% -- Declare? Encapsulate? Ignore? Or<a name="line.239"></a>
<FONT color="green">240</FONT> // dance widdershins about the instruction cache?<a name="line.240"></a>
<FONT color="green">241</FONT> }<a name="line.241"></a>
<FONT color="green">242</FONT> }<a name="line.242"></a>
<FONT color="green">243</FONT> <a name="line.243"></a>
<FONT color="green">244</FONT> return m_yield;<a name="line.244"></a>
<FONT color="green">245</FONT> }<a name="line.245"></a>
<FONT color="green">246</FONT> <a name="line.246"></a>
<FONT color="green">247</FONT> /** Transfer control to another coroutine which has already been started and<a name="line.247"></a>
<FONT color="green">248</FONT> * is waiting on this CoroutineManager. We won't return from this call<a name="line.248"></a>
<FONT color="green">249</FONT> * until that routine has relinquished control.<a name="line.249"></a>
<FONT color="green">250</FONT> *<a name="line.250"></a>
<FONT color="green">251</FONT> * %TBD% What should we do if toCoroutine isn't registered? Exception?<a name="line.251"></a>
<FONT color="green">252</FONT> *<a name="line.252"></a>
<FONT color="green">253</FONT> * @param arg_object A value to be passed to the other coroutine.<a name="line.253"></a>
<FONT color="green">254</FONT> * @param thisCoroutine Integer identifier for this coroutine. This is the<a name="line.254"></a>
<FONT color="green">255</FONT> * ID we watch for to see if we're the ones being resumed.<a name="line.255"></a>
<FONT color="green">256</FONT> * @param toCoroutine Integer identifier for the coroutine we wish to<a name="line.256"></a>
<FONT color="green">257</FONT> * invoke. <a name="line.257"></a>
<FONT color="green">258</FONT> * @exception java.lang.NoSuchMethodException if toCoroutine isn't a<a name="line.258"></a>
<FONT color="green">259</FONT> * registered member of this group. %REVIEW% whether this is the best choice.<a name="line.259"></a>
<FONT color="green">260</FONT> * */<a name="line.260"></a>
<FONT color="green">261</FONT> public synchronized Object co_resume(Object arg_object,int thisCoroutine,int toCoroutine) throws java.lang.NoSuchMethodException<a name="line.261"></a>
<FONT color="green">262</FONT> {<a name="line.262"></a>
<FONT color="green">263</FONT> if(!m_activeIDs.get(toCoroutine))<a name="line.263"></a>
<FONT color="green">264</FONT> throw new java.lang.NoSuchMethodException(XMLMessages.createXMLMessage(XMLErrorResources.ER_COROUTINE_NOT_AVAIL, new Object[]{Integer.toString(toCoroutine)})); //"Coroutine not available, id="+toCoroutine);<a name="line.264"></a>
<FONT color="green">265</FONT> <a name="line.265"></a>
<FONT color="green">266</FONT> // We expect these values to be overwritten during the notify()/wait()<a name="line.266"></a>
<FONT color="green">267</FONT> // periods, as other coroutines in this set get their opportunity to run.<a name="line.267"></a>
<FONT color="green">268</FONT> m_yield=arg_object;<a name="line.268"></a>
<FONT color="green">269</FONT> m_nextCoroutine=toCoroutine;<a name="line.269"></a>
<FONT color="green">270</FONT> <a name="line.270"></a>
<FONT color="green">271</FONT> notify();<a name="line.271"></a>
<FONT color="green">272</FONT> while(m_nextCoroutine != thisCoroutine || m_nextCoroutine==ANYBODY || m_nextCoroutine==NOBODY)<a name="line.272"></a>
<FONT color="green">273</FONT> {<a name="line.273"></a>
<FONT color="green">274</FONT> try <a name="line.274"></a>
<FONT color="green">275</FONT> {<a name="line.275"></a>
<FONT color="green">276</FONT> // System.out.println("waiting...");<a name="line.276"></a>
<FONT color="green">277</FONT> wait();<a name="line.277"></a>
<FONT color="green">278</FONT> }<a name="line.278"></a>
<FONT color="green">279</FONT> catch(java.lang.InterruptedException e)<a name="line.279"></a>
<FONT color="green">280</FONT> {<a name="line.280"></a>
<FONT color="green">281</FONT> // %TBD% -- Declare? Encapsulate? Ignore? Or<a name="line.281"></a>
<FONT color="green">282</FONT> // dance deasil about the program counter?<a name="line.282"></a>
<FONT color="green">283</FONT> }<a name="line.283"></a>
<FONT color="green">284</FONT> }<a name="line.284"></a>
<FONT color="green">285</FONT> <a name="line.285"></a>
<FONT color="green">286</FONT> if(m_nextCoroutine==NOBODY)<a name="line.286"></a>
<FONT color="green">287</FONT> {<a name="line.287"></a>
<FONT color="green">288</FONT> // Pass it along<a name="line.288"></a>
<FONT color="green">289</FONT> co_exit(thisCoroutine);<a name="line.289"></a>
<FONT color="green">290</FONT> // And inform this coroutine that its partners are Going Away<a name="line.290"></a>
<FONT color="green">291</FONT> // %REVIEW% Should this throw/return something more useful?<a name="line.291"></a>
<FONT color="green">292</FONT> throw new java.lang.NoSuchMethodException(XMLMessages.createXMLMessage(XMLErrorResources.ER_COROUTINE_CO_EXIT, null)); //"CoroutineManager recieved co_exit() request");<a name="line.292"></a>
<FONT color="green">293</FONT> }<a name="line.293"></a>
<FONT color="green">294</FONT> <a name="line.294"></a>
<FONT color="green">295</FONT> return m_yield;<a name="line.295"></a>
<FONT color="green">296</FONT> }<a name="line.296"></a>
<FONT color="green">297</FONT> <a name="line.297"></a>
<FONT color="green">298</FONT> /** Terminate this entire set of coroutines. The others will be<a name="line.298"></a>
<FONT color="green">299</FONT> * deregistered and have exceptions thrown at them. Note that this<a name="line.299"></a>
<FONT color="green">300</FONT> * is intended as a panic-shutdown operation; under normal<a name="line.300"></a>
<FONT color="green">301</FONT> * circumstances a coroutine should always end with co_exit_to() in<a name="line.301"></a>
<FONT color="green">302</FONT> * order to politely inform at least one of its partners that it is<a name="line.302"></a>
<FONT color="green">303</FONT> * going away.<a name="line.303"></a>
<FONT color="green">304</FONT> *<a name="line.304"></a>
<FONT color="green">305</FONT> * %TBD% This may need significantly more work. <a name="line.305"></a>
<FONT color="green">306</FONT> *<a name="line.306"></a>
<FONT color="green">307</FONT> * %TBD% Should this just be co_exit_to(,,CoroutineManager.PANIC)?<a name="line.307"></a>
<FONT color="green">308</FONT> *<a name="line.308"></a>
<FONT color="green">309</FONT> * @param thisCoroutine Integer identifier for the coroutine requesting exit.<a name="line.309"></a>
<FONT color="green">310</FONT> * */<a name="line.310"></a>
<FONT color="green">311</FONT> public synchronized void co_exit(int thisCoroutine)<a name="line.311"></a>
<FONT color="green">312</FONT> {<a name="line.312"></a>
<FONT color="green">313</FONT> m_activeIDs.clear(thisCoroutine);<a name="line.313"></a>
<FONT color="green">314</FONT> m_nextCoroutine=NOBODY; // %REVIEW%<a name="line.314"></a>
<FONT color="green">315</FONT> notify();<a name="line.315"></a>
<FONT color="green">316</FONT> }<a name="line.316"></a>
<FONT color="green">317</FONT> <a name="line.317"></a>
<FONT color="green">318</FONT> /** Make the ID available for reuse and terminate this coroutine,<a name="line.318"></a>
<FONT color="green">319</FONT> * transferring control to the specified coroutine. Note that this<a name="line.319"></a>
<FONT color="green">320</FONT> * returns immediately rather than waiting for any further coroutine<a name="line.320"></a>
<FONT color="green">321</FONT> * traffic, so the thread can proceed with other shutdown activities.<a name="line.321"></a>
<FONT color="green">322</FONT> *<a name="line.322"></a>
<FONT color="green">323</FONT> * @param arg_object A value to be passed to the other coroutine.<a name="line.323"></a>
<FONT color="green">324</FONT> * @param thisCoroutine Integer identifier for the coroutine leaving the set.<a name="line.324"></a>
<FONT color="green">325</FONT> * @param toCoroutine Integer identifier for the coroutine we wish to<a name="line.325"></a>
<FONT color="green">326</FONT> * invoke. <a name="line.326"></a>
<FONT color="green">327</FONT> * @exception java.lang.NoSuchMethodException if toCoroutine isn't a<a name="line.327"></a>
<FONT color="green">328</FONT> * registered member of this group. %REVIEW% whether this is the best choice.<a name="line.328"></a>
<FONT color="green">329</FONT> * */<a name="line.329"></a>
<FONT color="green">330</FONT> public synchronized void co_exit_to(Object arg_object,int thisCoroutine,int toCoroutine) throws java.lang.NoSuchMethodException<a name="line.330"></a>
<FONT color="green">331</FONT> {<a name="line.331"></a>
<FONT color="green">332</FONT> if(!m_activeIDs.get(toCoroutine))<a name="line.332"></a>
<FONT color="green">333</FONT> throw new java.lang.NoSuchMethodException(XMLMessages.createXMLMessage(XMLErrorResources.ER_COROUTINE_NOT_AVAIL, new Object[]{Integer.toString(toCoroutine)})); //"Coroutine not available, id="+toCoroutine);<a name="line.333"></a>
<FONT color="green">334</FONT> <a name="line.334"></a>
<FONT color="green">335</FONT> // We expect these values to be overwritten during the notify()/wait()<a name="line.335"></a>
<FONT color="green">336</FONT> // periods, as other coroutines in this set get their opportunity to run.<a name="line.336"></a>
<FONT color="green">337</FONT> m_yield=arg_object;<a name="line.337"></a>
<FONT color="green">338</FONT> m_nextCoroutine=toCoroutine;<a name="line.338"></a>
<FONT color="green">339</FONT> <a name="line.339"></a>
<FONT color="green">340</FONT> m_activeIDs.clear(thisCoroutine);<a name="line.340"></a>
<FONT color="green">341</FONT> <a name="line.341"></a>
<FONT color="green">342</FONT> notify();<a name="line.342"></a>
<FONT color="green">343</FONT> }<a name="line.343"></a>
<FONT color="green">344</FONT> }<a name="line.344"></a>
</PRE>
</BODY>
</HTML>