Nathan, I have just thrown a ping to Rustem. Even if found, this tool hardly can be donated without upper level managerial support. Maybe Xiao Feng would help us.
Honestly, I'm reluctant native bridge supporter myself. I dare to think of it as another layer of wrappers. Removing the wrappers would result in more compact code. I see the only viable argument in the native bridge defense is "java is easier, why should we use C". Thanks. On Thu, Mar 26, 2009 at 4:52 AM, Nathan Beyer <[email protected]> wrote: > On Wed, Mar 25, 2009 at 2:53 PM, Mark Hindess > <[email protected]> wrote: >> >> In message <[email protected]>, Nathan Beyer >> writes: >>> >>> On Mar 25, 2009, at 5:40 AM, Tim Ellison <[email protected]> wrote: >>> >>> > Nathan Beyer wrote: >>> >> On Tue, Mar 24, 2009 at 9:10 AM, Tim Ellison >>> >> <[email protected]> wrote: >>> >>> 3. Various AWT/Swing crashes/ failures >>> >> >>> >> Linux AWT/Swing crashes - works on Ubuntu 8.04, doesn't on 8.10 >>> >> https://issues.apache.org/jira/browse/HARMONY-6123 >>> > >>> > Looks like a problem in the X.11 libraries, and looking around it >>> > seems that we are far from the only ones who have uncovered this problem. >>> > >>> Agreed, but I got the impression that the new behavior is considered >>> correct and it will be up to apps to fix their own code. Have you >>> found any indication to the contrary? >> >> Well, there have been mistakes in the past - such as nested locking not >> working as documented in the XLockDisplay man page and with locks being >> held by the toolkit when user callbacks were invoked - but I think it is >> quite likely that we need to do something to fix this. >> >> We currently call XInitThreads to allow multi-threaded support but we >> do not actually seem to call XLockDisplay. I don't think this can be >> correct though I don't know which xlib calls need to be locking - I'm >> guessing at least the two mentioned in your JIRA. If we had access >> to the native bridge tool, we could probably make a safe fix of just >> wrapping all Xlib calls with a lock but that would probably be overkill. >> Having access to the native bridge tool would be useful anyway.[0] > > Is anyone from Intel still around that could provide some insight into > the 'native bridge tool'? Anyone know who we could contact to maybe > get some more information? This would help out with some of the Vista > issues I'm seeing in Swing as well. > >> >> I will try to get an ubuntu 8.10 kvm image installed and have a look at this >> problem but since awt/swing are not really a priority for me. >> >>> > Since it is not a regression, and apparently not caused by anything we >>> > can fix (unless we can find a workaround), I propose that we declare >>> > it a "Non-Blocker" for M9. >> >> +1 >> >>> I'm fine with that. Maybe indicate it is a known issue. >> >> 1+ It should be mentioned in the release notes. >> >> Regards, >> Mark. >> >> [0] I think there are some modularity problems lurking here... I think >> luni depends on the org.apache.harmony.misc.accessors which depends on >> some native bridge code in awt. I suspect the common native bridge >> probably should be brought back in to the misc module. >> >> >> > -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://www.telecom-express.ru/ http://people.apache.org/~aaf/
