<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
For your explanation to Question (1),
<blockquote>
<pre class="moz-quote-pre" wrap=""><font color="#0080ff">Because the definition of “EventTriggerId” (in “UsageEnvironment/include/UsageEnvironment.hh”) is “u_int32_t”, <b class="moz-txt-star"><span class="moz-txt-tag">*</span>all<span class="moz-txt-tag">*</span></b> implementations (not just the default implementation) support no more than 32 different event triggers.</font>
</pre>
</blockquote>
<p>I don't think so. Total event trigger number can be incremented
by changing the implementation, by not assuming that <font
face="monospace">"EventTriggerId"(u_int32_t) </font>has only
one bit set on and others off. What I mean is, "<font
face="monospace">EventTriggerId</font>" can range in { 1, 2, 3,
4, 5, ..., 2^32 - 1 }, not just { 1, 2, 4, 8, 16, ..., 2^31 }.
Take system socket file descriptor as an example. Socket
descriptor is usually implemented by int(or other int-releated).
We can assume that system limit one process to 1024 simultanously
openned file descriptor, then socket descriptor can range from 1
to 1023 (not very precise), and this is supported by
implementation similar to your implementation of event trigger,
but with a bit recording system of "<font face="monospace">fd_set</font>,
which may be 1024 bits size. I believe live555's event trigger
upper limit can be pushed by changing the implementation of the
generation and recording system of "<font face="monospace">EventTriggerId</font>",
just like system socket's implementation. But if <font
face="monospace">"<font color="#ffffff">BasicUsageEnvironment0.hh"</font></font><font
color="#ffffff"> is also the not-to-modify public interface,
then the limit can't be changed since "<font face="monospace">EventTriggerId
BasicTaskScheduler0::fTriggersAwaitingHandling</font>" already
has type "</font><font color="#ffffff"><font color="#ffffff"><font
face="monospace">EventTriggerId</font></font>", which only
has 32-bit to set to distinguish different events.</font></p>
<p><font color="#ffffff">And</font></p>
<blockquote>
<pre class="moz-quote-pre" wrap=""><font color="#0080ff">do {fTriggersAwaitingHandling |= eventTriggerId} while ((fTriggersAwaitingHandling&eventTriggerId) == 0); // (a)</font>
</pre>
</blockquote>
<p>There may still be some risk that "<font face="monospace">fTriggersAwaitingHandling</font>"
will be corrupted. The code above can only ensure that the bit is
really set by "TriggerEvent" function, but it may corrupt other
operation on it inside event loop in "<font face="monospace">BasicTaskScheduler::SingleStep</font>":</p>
<blockquote>
<p><font face="monospace">fTriggersAwaitingHandling &=~
fLastUsedTriggerMask; // (b)<br>
</font></p>
</blockquote>
<p>If the order of (a) and (b) is following:</p>
<blockquote>
<p>1. (b) Read.</p>
<p>2. (b) Modify.</p>
<p>3. (a) Read, Modify.</p>
<p>4. (b) Write back to <font face="monospace">fTriggersAwaitingHandling
</font>.</p>
<p>5. (a) Write back to <font face="monospace">fTriggersAwaitingHandling
</font>.</p>
</blockquote>
<p>And (a) operation is completed, but (b) is not, since (b)'s write
operation is overwrited by (a)'s write. I believe some protection
to <font face="monospace">fTriggersAwaitingHandling</font>'s
Read-Write is needed. And if you decide to change the
implementation of event trigger(use other data structrue to
recording event as I describe above), the exclusive Read-Write
mechanism is still needed.</p>
<p>For solution, I didn't come up some ideas. Maybe spinlock is
possible, but I'm not sure it can be implemented purely by normal
C++(without other library support).</p>
<p><br>
</p>
<p>By mitshan.<br>
</p>
</body>
</html>