firing event to listeners
in Mr. Morris's book: Interactive TV standards,
A hostile xlet should only suffer itself when it misbehaves.
I try to realize the concept, one thing I consider now is the threads
used to fire event to listeners registered by xlets.
There are many entities in MHP middleware may let xlets register listeners, for example, ServiceContext.addListener() or SIDatabase.addXXXListener()...
What if the hostile xlet implements the methods of the listener like the following:
public void receiveEvent(Event e) {
while(true) {;}
}
Of course, the xlet may be performing its work normally, there is no way for middleware to determine precisely why the thread firing the event does not return from xlet.
Thus, I think the way to handle this situation is that the middleware uses one thread per xlet to dispatch all types of event to all listeners registed by the xlet. If the thread is kidnaped by the xlet, it suffers itself.
Since it kidnaps the thread which works to dispatch events to the xlet's listeners, it no longer can receive any event.
But I wonder one situation may happen:
The xlet may receive one event, and it performs some works by the thread dispatching event. And it expects another event's arrival to continue its work.
So is it safe to implement event dispatching this way? Can I assume that the situation above never happens?
any reply is appreciated.
[1463 byte] By [
woodheada] at [2007-10-3 4:20:19]
You could pretty much assume no Xlet developer would write code like an
infinite loop voluntarily. It is a general principle that you must not block or
capture call-back threads I believe a great many STBs would watchdog
their threads and kill any application waiting for a second, third... thread to
deliver events before the first one's released.
However, I cannot find this in the spec.
//Enver
PS: Try a paint(Graphics g) method with an infinite loop in a web browser :)
Thank you for your replies.
Yes as a content provider, one should have tested their xlets very well before broadcasting them to DTV subscribers.
So it is safe to assume that no xlet would implement this way.
However, as xlet grows more complicated, a good middleware implementation still needs to consider how to handle the misbehaving of an xlet, even this is not caused intentionally by the xlet.
To realize the concept described in Mr. Morris's book, all threads which may execute xlet's codes (those include the thread executing methods defined in Xlet interface, the threads dispatching events to xlet's listeners, and so on) shall be managed well. For example, for each xlet the middleware allocates a fix number of threads to serve the xlet. And those threads are not shared by different xlets. If any thread misbehaves (e.g. not returning), the xlet suffers itself. Or in other word, affects only itself. And of course, the middleware shall still work instead of getting crashed due to those misbehaved xlets.
For a middleware developer, how to implement a flexible and robust middleware may not be the most difficult task, I think how to determine whether an xlet misbehaves is more difficult. Maybe the best way to decide this is left to the user.
