platform-core/documents/user_settings/background_notification.html - gerrit/www.eclipse.org/eclipse - Git at Google

 <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 <html>
 <head>
 <title>Eclipse Platform/Core</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 <link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
 </head>
 <body>
 <center>
 	<font class=indextop>core</font><br>
 	<font class=indexsub>the foundation of the platform</font><p></p>
 	<a href="../../main.html">[home]</a>
 	<a href="../../documents.html">[documents]</a>
 	<a href="../../downloads.html">[downloads]</a>
 	<a href="../../resources.html">[resources]</a>
 	<a href="../../planning.html">[planning]</a>
 	<a href="../../testing.html">[testing]</a>
 </center>
 <br>
 <table BORDER=0 CELLPADDING=2 WIDTH="100%" >
 	<tr>
 		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Background Notification</font></b></td>
 	</tr>
 	<tr>
 		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
     	<td WIDTH="98%"><b>Summary</b>
 			<blockquote>

         <p>Currently the preference mechanism sends out change notification (for
           both preference value changes and node changes) immediately after the
           action is performed and before the method returns. In essence, we set
           the preference value, iterate over all the appropriate listeners, notify
           each with a constructed change event, and then return from the #setValue
           method. </p>

         <p>There are a few obvious problems with this approach and the Core team
           is considering moving event notification into a background job to work
           around these problems. The purpose of this document is to outline the
           problems at the Core level and to guage the effect on clients at the
           UI level.</p>
 			</blockquote>
 			<p>&nbsp;</p>
 		</td>
 	</tr>
 	<tr>
 		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Core Issues</font></b></td>
 	</tr>
 	<tr>
 		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
     	<td WIDTH="98%"><b>Pros for moving noticication to the background</b>
 			<p><ol>
 				<li>Protect against deadlocks. When calling client code, there is always the chance for deadlock. Consider
 				the following block of seemingly innocent code:<br>
 				<code><pre>
 synchronized void foo() {
    ...
    preferences.setValue(key, value);
    ...
 }</pre></code>
 			With the current code the notification will occur within the sychronized method. This means there is a chance that
 			the client listener code can deadlock.
 			</p></li>
 				<li>Protect against bad listeners. Consider the following code:<br>
 				<code>
           <pre>
 new IEclipsePreferences.IPreferenceChangeListener() {
    public void preferenceChanged(PreferenceChangeEvent event) {
       ...
       preferences.setValue(key, value);
       ...
    }
 }
 </pre>
           </code>
           <p> In the best-case scenerio, the listener is reacting to a change
             in preference-key-1 and setting a new value for preference-key-2.
             This will send off another round of notification and that will be
             the end of it. In the worse-case scenerio the client is making a change
             to the same preference key that is in the event. In this case, we
             are looking at a recursive call and, eventually, stack overflow problems.
           </p>
         </li>

         <li>Performance. Clients are able to write whatever they want in their
           listener code and it may not be performant. If we return immediately
           from the call to #setValue, then the clients who are calling this method
           will not have to wait before continuing their execution.</li>
 			</ol></p>
 		</td>
 	</tr>
 	<tr>
 		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
     	<td WIDTH="98%"><b>Cons against moving noticication to the background</b>
 			<ol>
 				<li>
           <p>Client assumptions about the current code. Although it isn't specified
             in the API, existing clients could be relying on the current implementation
             and they could be expecting change events to happen immediately after
             the change itself, and in a sychronous manner. </p>
         </li>
 			</ol>
 			<p>&nbsp;</p>
 		</td>
 	</tr>
 	<tr>
 		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">UI Issues</font></b></td>
 	</tr>
 	<tr>
 		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
     	<td WIDTH="98%"><b>Problems with the current implementation</b>
 			<ol>
         <li>The JFace API does not explicitly specify that preference changes
           must happen (and preference change events occur) within the UI thread.
           In the current code base, any clients who call the JFace preference
           APIs in the non-UI thread risk having problems occur. <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=77280">Bug
           77280</a> describes this problem. In fact, it has already been acknowledged
           that there are clients who call this code from the non-UI thread and
           hence the creation of the <code>IPreferenceStore#putValue</code> API
           method. This method sets values in the preference store without providing
           listener notification.
           <p></p>
         </li>
         <li>The JFace API does not specify whether or not the property change
           notification happens in the same thread that the change happened. </li>
       </ol>
 			<p>&nbsp;</p>
 		</td>
 	</tr>
 	<tr>
 		<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
     	<td WIDTH="98%"><b>Problems with having the Core notification in the background</b>
 			<ol>

         <li>Client assumptions about the current code. Clients may be relying
           on the fact that by the time they return from their <code>IPreferenceStore#setValue</code>
           calls, all client listeners will have been notified.</li>
 			</ol>
 			<p>&nbsp;</p>
 		</td>
 	</tr>
 </table>


 </body>
 </html>
	<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
	<html>
	<head>
	<title>Eclipse Platform/Core</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
	</head>
	<body>
	<center>
	<font class=indextop>core</font><br>
	<font class=indexsub>the foundation of the platform</font><p></p>
	<a href="../../main.html">[home]</a>
	<a href="../../documents.html">[documents]</a>
	<a href="../../downloads.html">[downloads]</a>
	<a href="../../resources.html">[resources]</a>
	<a href="../../planning.html">[planning]</a>
	<a href="../../testing.html">[testing]</a>
	</center>
	<br>
	<table BORDER=0 CELLPADDING=2 WIDTH="100%" >
	<tr>
	<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Background Notification</font></b></td>
	</tr>
	<tr>
	<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
	<td WIDTH="98%"><b>Summary</b>
	<blockquote>

	<p>Currently the preference mechanism sends out change notification (for
	both preference value changes and node changes) immediately after the
	action is performed and before the method returns. In essence, we set
	the preference value, iterate over all the appropriate listeners, notify
	each with a constructed change event, and then return from the #setValue
	method. </p>

	<p>There are a few obvious problems with this approach and the Core team
	is considering moving event notification into a background job to work
	around these problems. The purpose of this document is to outline the
	problems at the Core level and to guage the effect on clients at the
	UI level.</p>
	</blockquote>
	<p> </p>
	</td>
	</tr>
	<tr>
	<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Core Issues</font></b></td>
	</tr>
	<tr>
	<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
	<td WIDTH="98%"><b>Pros for moving noticication to the background</b>
	<p><ol>
	<li>Protect against deadlocks. When calling client code, there is always the chance for deadlock. Consider
	the following block of seemingly innocent code:<br>
	<code><pre>
	synchronized void foo() {
	...
	preferences.setValue(key, value);
	...
	}</pre></code>
	With the current code the notification will occur within the sychronized method. This means there is a chance that
	the client listener code can deadlock.
	</p></li>
	<li>Protect against bad listeners. Consider the following code:<br>
	<code>
	<pre>
	new IEclipsePreferences.IPreferenceChangeListener() {
	public void preferenceChanged(PreferenceChangeEvent event) {
	...
	preferences.setValue(key, value);
	...
	}
	}
	</pre>
	</code>
	<p> In the best-case scenerio, the listener is reacting to a change
	in preference-key-1 and setting a new value for preference-key-2.
	This will send off another round of notification and that will be
	the end of it. In the worse-case scenerio the client is making a change
	to the same preference key that is in the event. In this case, we
	are looking at a recursive call and, eventually, stack overflow problems.
	</p>
	</li>

	<li>Performance. Clients are able to write whatever they want in their
	listener code and it may not be performant. If we return immediately
	from the call to #setValue, then the clients who are calling this method
	will not have to wait before continuing their execution.</li>
	</ol></p>
	</td>
	</tr>
	<tr>
	<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
	<td WIDTH="98%"><b>Cons against moving noticication to the background</b>
	<ol>
	<li>
	<p>Client assumptions about the current code. Although it isn't specified
	in the API, existing clients could be relying on the current implementation
	and they could be expecting change events to happen immediately after
	the change itself, and in a sychronous manner. </p>
	</li>
	</ol>
	<p> </p>
	</td>
	</tr>
	<tr>
	<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">UI Issues</font></b></td>
	</tr>
	<tr>
	<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
	<td WIDTH="98%"><b>Problems with the current implementation</b>
	<ol>
	<li>The JFace API does not explicitly specify that preference changes
	must happen (and preference change events occur) within the UI thread.
	In the current code base, any clients who call the JFace preference
	APIs in the non-UI thread risk having problems occur. <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=77280">Bug
	77280</a> describes this problem. In fact, it has already been acknowledged
	that there are clients who call this code from the non-UI thread and
	hence the creation of the <code>IPreferenceStore#putValue</code> API
	method. This method sets values in the preference store without providing
	listener notification.
	<p></p>
	</li>
	<li>The JFace API does not specify whether or not the property change
	notification happens in the same thread that the change happened. </li>
	</ol>
	<p> </p>
	</td>
	</tr>
	<tr>
	<td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
	<td WIDTH="98%"><b>Problems with having the Core notification in the background</b>
	<ol>

	<li>Client assumptions about the current code. Clients may be relying
	on the fact that by the time they return from their <code>IPreferenceStore#setValue</code>
	calls, all client listeners will have been notified.</li>
	</ol>
	<p> </p>
	</td>
	</tr>
	</table>


	</body>
	</html>