Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

11991 Posts in 1587 Topics- by 3509 Members - Latest Member: lioneltenel

27. May 2012, 03:08:56 am
Xith3D CommunityGeneral CategoryNews (Moderators: Marvin Fröhlich, 'n ddrylliog)SWT support is ready
Pages: 1 [2]
Print
Author Topic: SWT support is ready  (Read 4764 times)
Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4381


May the 4th, be with you...


View Profile
« Reply #15 on: 12. February 2007, 07:47:36 pm »

I missed this request for the files via e-mail.  I run Mac OS X 10.4.8.

Hmm... That could be the reason. We could not test this on Mac so far.

I am happy to announce that I have fixed the SWT threading issue in my local environment.  I need to perform more a lot more testing as well as gain developer SVN access before I commit the changes.  There was an issue with illegal creation of SWT Displays that I fixed as well.

Cool. Do you also get it to run in a separate thread?

Edit: I'm going to take the rest of the day off.  I'm exhausted after putting in 110 hours in the last 8 days.  Hopefully, somebody can grant me SVN access overnight so I can test and commit the fixes tomorrow.

Granted.

Marvin
Logged
horati
Global Moderator
Getting respectable
*****
Offline Offline

Posts: 393


View Profile
« Reply #16 on: 12. February 2007, 09:25:59 pm »

Yep, but I had to bundle the deepest part of the renderer into a Runnable and submit it to the SWT thread for execution.  SWT only allows the Thread that created the Display to manipulate it... and they do check.  They don't always check and the amount of checking varies by implementation; however, manipulation by outside threads is never allowed.

Here is a quote from a method inside the Mac implementation of org.eclipse.swt.widgets.Widget.  I didn't check the other jars but assume that code this fundamental should be the same cross-platform.
Code:
/**
 * Throws an <code>SWTException</code> if the receiver can not
 * be accessed by the caller. This may include both checks on
 * the state of the receiver and more generally on the entire
 * execution context. This method <em>should</em> be called by
 * widget implementors to enforce the standard SWT invariants.
 * <p>
 * Currently, it is an error to invoke any method (other than
 * <code>isDisposed()</code>) on a widget that has had its
 * <code>dispose()</code> method called. It is also an error
 * to call widget methods from any thread that is different
 * from the thread that created the widget.
 * </p><p>
 * In future releases of SWT, there may be more or fewer error
 * checks and exceptions may be thrown for different reasons.
 * </p>
 *
 * @exception SWTException <ul>
 *    <li>ERROR_WIDGET_DISPOSED - if the receiver has been disposed</li>
 *    <li>ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver</li>
 * </ul>
 */
protected void checkWidget () {
Display display = this.display;
if (display == null) error (SWT.ERROR_WIDGET_DISPOSED);
if (display.thread != Thread.currentThread ()) error (SWT.ERROR_THREAD_INVALID_ACCESS);
if ((state & DISPOSED) != 0) error (SWT.ERROR_WIDGET_DISPOSED);
}

Every stack trace I found had this line in it
Code:
if (display.thread != Thread.currentThread ()) error (SWT.ERROR_THREAD_INVALID_ACCESS);
« Last Edit: 12. February 2007, 09:28:04 pm by horati » Logged

Kevin
"It may not seem like a big deal, but ignorance of character encoding issues leads to insidious code rot akin to y2k."
http://stackoverflow.com/users/3474/sylvarking
Pages: 1 [2]
Print
Jump to:  

Theme orange-lt created by panic