2009/3/25 Alexei Fedotov <[email protected]>: > 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.
Even if we can't get the actual tool - it would be nice to know more about what it did and what input was used. > > 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/ >
