Updated StatCVS report...
I updated the StatCVS report for GNU Classpath CVS: http://www.object-refinery.com/classpath/statcvs/ All the usual disclaimers about meaningless statistics apply! Regards, Dave
[Bug classpath/26046] checking for files doesn't work while cross-compiling
--- Comment #1 from mark at gcc dot gnu dot org 2006-01-31 12:42 --- Dalibor could you take a look at this? You have been doing some cross-compiling for kaffe recently. I don't know if pkg-config actually supports cross-compiling to be honest. -- mark at gcc dot gnu dot org changed: What|Removed |Added CC||robilad at kaffe dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26046 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: New native layer
Dalibor Topic wrote: On Mon, 2006-01-30 at 12:20 -0500, Brian Jones wrote: It would be nice, I believe, to re-use libraries that have handled most of the "porting" and "wrapping" for you such as APR (http://apr.apache.org/), or NPR (http://www.mozilla.org/projects/nspr/) to platforms GNU Classpath might care to support. You might also find glib useful, http://developer.gnome.org/arch/gtk/glib.html. I believe that's the reason why neither APR nor NSPR (nor other similar projects) have seen wide spread acceptance, even though they have been around for many years now: they don't really pay off enough for people to rewrite their existing code bases to them. Okay, but I brought it up since the work Guilhem Lavaux is doing sounds an awful lot like a rewrite. Although technically I think you can just run the macro processor by hand to get the current real source code for say Linux and autoconfiscate it from there. Or you could go back a couple of years and look in native/ for the original autoconf/posix version of the libraries and move forward from there. See also what the OpenBSD developers did as one of the first things, once they 'forked' Apache web server 1.3.x after the Apache license change: rip out APR and replace its use by plain old posix functions, since those were more maintainable for them. Yea, I think the point for me would be to keep Classpath's java hackers out of the business of writing native code, and especially out of the business of porting native code for such common idioms as generic file operations, network operations, etc. Anyway, that was my $0.02, Brian
Re: New native layer
Brian Jones wrote: Dalibor Topic wrote: On Mon, 2006-01-30 at 12:20 -0500, Brian Jones wrote: It would be nice, I believe, to re-use libraries that have handled most of the "porting" and "wrapping" for you such as APR (http://apr.apache.org/), or NPR (http://www.mozilla.org/projects/nspr/) to platforms GNU Classpath might care to support. You might also find glib useful, http://developer.gnome.org/arch/gtk/glib.html. I believe that's the reason why neither APR nor NSPR (nor other similar projects) have seen wide spread acceptance, even though they have been around for many years now: they don't really pay off enough for people to rewrite their existing code bases to them. Okay, but I brought it up since the work Guilhem Lavaux is doing sounds an awful lot like a rewrite. Although technically I think you can just run the macro processor by hand to get the current real source code for say Linux and autoconfiscate it from there. Or you could go back a couple of years and look in native/ for the original autoconf/posix version of the libraries and move forward from there. See also what the OpenBSD developers did as one of the first things, once they 'forked' Apache web server 1.3.x after the Apache license change: rip out APR and replace its use by plain old posix functions, since those were more maintainable for them. Yea, I think the point for me would be to keep Classpath's java hackers out of the business of writing native code, and especially out of the business of porting native code for such common idioms as generic file operations, network operations, etc. Hi Brian, The code is not really a rewrite. Actually I am just moving out TARGET layer and replacing it with native function call with an API not so different than posix. My idea is that these function calls should be purely POSIX (so that classpath's hackers does not have deal with subtleties). Anyway, as I have already said it, seeing the amount of code to do pure administrations in the JNI world, it is easier to read autoconfiscated code which is completely outside the JNI code (again look at javanet). The advantage of this method is that some VMs may want to reroute these syscalls and it is easy to do so using this semi-abstract interface without rewriting anything. Regards, Guilhem.
Re: New native layer
Hi Brian, hi list, > Yea, I think the point for me would be to keep Classpath's java hackers > out of the business of writing native code, and especially out of the > business of porting native code for such common idioms as generic file > operations, network operations, etc. BTW, Torsten, the man who first wrote the target native layer, mostly works on native code and porting of this to platforms you would not dream of. He is hardly a 'Classpath java hacker'. If the world was so nice that posix and autoconf is the solution to everything, then such work would hardly be necessary. But this seems to be a little behind the horizon of the brave GNU world. Man, all this narrow-mindedness sets me up, I think I better go back to java hacking ;-) Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Bug classpath/24876] Regex failure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |0.21 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24876 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: New native layer
On Jan 31, 2006, at 11:32 AM, Roman Kennke wrote: Hi Brian, hi list, Yea, I think the point for me would be to keep Classpath's java hackers out of the business of writing native code, and especially out of the business of porting native code for such common idioms as generic file operations, network operations, etc. BTW, Torsten, the man who first wrote the target native layer, mostly works on native code and porting of this to platforms you would not dream of. That is arrogant. I'm sure everyone here who hacks on Classpath has worked with interesting technologies, and are all great engineers, each in his own right. So let's stop measuring cocks here, OK? He is hardly a 'Classpath java hacker'. If the world was so nice that posix and autoconf is the solution to everything, then such work would hardly be necessary. But this seems to be a little behind the horizon of the brave GNU world. Man, all this narrow-mindedness sets me up, I think I better go back to java hacking ;-) GNU Classpath is STILL a GNU project, and above all, we are trying to support free platforms, and are first of all concerned with supporting GNU (in it's GNU/Linux form). There is reams of evidence that targeting mostly POSIX systems, and handling the divergences with autoconf, produces a lot of software that is usable in a lot of places (witness, all the programs of the GNU project). Please, recognize that: - Macro-based portability layers like this are ugly and extremely hard to maintain and debug. - The benefits of such a thing never materialized anyway, because the only implementation available is for POSIX-like platforms. So it STILL relied on POSIX and autoconf. We have the responsibility, as contributors to a GNU project, to maintain the project for the GNU system. GNU is sorta-POSIX, as are a lot of other interesting platforms, and targeting them earns us, as free software contributors -- not necessarily other groups or companies that want to use Classpath -- a lot. I see these "native portability layers" as being counter to that goal, and they especially don't make sense given that there's no other free implementations for platforms other than what we are targeting. You can call that narrow-minded if you want, but we have to have goals and rules for the project, and they should be mandated by the larger project of which we are a part, which is GNU.
[Bug classpath/26002] Another regex problem: \p{Nd}
--- Comment #5 from kaz at maczuka dot gcd dot org 2006-01-31 16:26 --- Fixed. -- kaz at maczuka dot gcd dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26002 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/25038] If the system clipboard is blocked by security manager, the VM-local cliboard is used.
--- Comment #2 from audriusa at bluewin dot ch 2006-01-31 19:56 --- 2005-12-04 Mark Wielaard <[EMAIL PROTECTED]> * javax/swing/TransferHandler (TransferAction.actionPerformed): Beep and return when clipboard is null. (getClipboard): Return null when access denied. (clipboard): Removed static field. -- audriusa at bluewin dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25038 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26046] New: checking for files doesn't work while cross-compiling
checking for pkg-config... /usr/src/sdk3000/tmp/staging/i686-linux/bin/pkg-config checking for QtCore QtGui >= 4.1.0... yes checking QT_CFLAGS... -DQT_SHARED -I/usr/src/sdk3000/tmp/staging/arm-linux/include -I/usr/src/sdk3000/tmp/staging/arm-linux/include/QtCore -I/usr/src/sdk3000/tmp/staging/arm-linux/include/QtGui checking QT_LIBS... -L/opt/QtPalmtop/lib -L/usr/src/sdk3000/tmp/staging/arm-linux/lib -L/usr/src/sdk3000/tmp/work/qtopia-core-4.1.0+20060131-r1/qtopia-core-opensource-src-4.1.1-snapshot-20060131/lib -lQtGui -lQtCore -lpng -ljpeg -lz -lm -lpthread -ldl checking for /usr/src/sdk3000/tmp/staging/arm-linux/include/QtGui/QWidget... configure: error: cannot check for file existence when cross compiling -- Summary: checking for files doesn't work while cross-compiling Product: classpath Version: 0.20 Status: UNCONFIRMED Severity: normal Priority: P3 Component: classpath AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hs4233 at mail dot mn-solutions dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26046 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug swing/26027] The new element, added to JList, does not appear (regression since 0.20)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |0.21 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26027 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/22873] java.util.regex.Matcher.group(int) differs from Sun's API
--- Comment #5 from cvs-commit at developer dot classpath dot org 2006-01-31 16:27 --- Subject: Bug 22873 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Ito Kazumitsu <[EMAIL PROTECTED]> 06/01/31 14:57:43 Modified files: . : ChangeLog gnu/regexp : REMatch.java Log message: 2006-01-31 Ito Kazumitsu <[EMAIL PROTECTED]> Fixes bug #22873 * gnu/regexp/REMatch(toString(int)): Throw IndexOutOfBoundsException for an invalid index and return null for a skipped group. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6231&tr2=1.6232&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/regexp/REMatch.java.diff?tr1=1.4&tr2=1.5&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22873 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26002] Another regex problem: \p{Nd}
--- Comment #4 from cvs-commit at developer dot classpath dot org
2006-01-31 15:51 ---
Subject: Bug 26002
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Ito Kazumitsu <[EMAIL PROTECTED]> 06/01/31 14:39:08
Modified files:
. : ChangeLog
gnu/regexp : RE.java RESyntax.java
Added files:
gnu/regexp : RETokenNamedProperty.java
Log message:
2006-01-30 Ito Kazumitsu <[EMAIL PROTECTED]>
Fixes bug #26002
* gnu/regexp/gnu/regexp/RE.java(initialize): Parse /\p{prop}/.
(NamedProperty): New inner class.
(getNamedProperty): New method.
(getRETokenNamedProperty): New Method.
* gnu/regexp/RESyntax.java(RE_NAMED_PROPERTY): New syntax falg.
* gnu/regexp/RETokenNamedProperty.java: New file.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6230&tr2=1.6231&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/regexp/RE.java.diff?tr1=1.13&tr2=1.14&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/regexp/RESyntax.java.diff?tr1=1.5&tr2=1.6&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/regexp/RETokenNamedProperty.java?rev=1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26002
___
Bug-classpath mailing list
Bug-classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: New native layer
Casey Marshall wrote: We have the responsibility, as contributors to a GNU project, to maintain the project for the GNU system. GNU is sorta-POSIX, as are a lot of other interesting platforms, and targeting them earns us, as free software contributors -- not necessarily other groups or companies that want to use Classpath -- a lot. I see these "native portability layers" as being counter to that goal, and they especially don't make sense given that there's no other free implementations for platforms other than what we are targeting. An alternative take with similar conclusion: There is a standard "native portability layer". It is called Posix. There are multiple implementations of this layer available for MS-Windows. Other platforms we are likely to support (such as OS-X) already support Posix. I.e. there is no need for an extra portability layer. That is not to say we cannot add hooks and conditional compilation in modest doses to support Windows and other non-Posix platforms. But any extra indirection that hurts performance on Posix (even trivially), or anything that makes the code harder to maintain and understand is generally inappropriate. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: New native layer
Hi Casey, Am Dienstag, den 31.01.2006, 12:37 -0800 schrieb Casey Marshall: > On Jan 31, 2006, at 11:32 AM, Roman Kennke wrote: > > > Hi Brian, hi list, > > > >> Yea, I think the point for me would be to keep Classpath's java > >> hackers > >> out of the business of writing native code, and especially out of the > >> business of porting native code for such common idioms as generic > >> file > >> operations, network operations, etc. > > > > BTW, Torsten, the man who first wrote the target native layer, mostly > > works on native code and porting of this to platforms you would not > > dream of. > > That is arrogant. I'm sure everyone here who hacks on Classpath has > worked with interesting technologies, and are all great engineers, > each in his own right. > > So let's stop measuring cocks here, OK? Sorry, I didn't want to sound arrogant or whatnot. I am only a bit upset about this braindead discussion again. I get the impression that there is a general opposition against real portability concerns within the GNU (Classpath?) project. Correct me if I am wrong. There certainly are parties that have portability demands that go beyong posix. Granted, Aicas is a commercial party and cannot publish every port. There is also Kaffe, which is 100% GPL and now also suggest something similar like the target layer, only somewhat nicer, and again it seems to turn out to be a fight against windmills. But after all, that is what we have the VM interface for and I for myself don't want to discuss C issues anymore and instead concentrate on getting the VM interface into a good shape (it already is IMO, needs some tweaks though) and let people with different opinions on native code fork/implement their own stuff below the VM interface. Cheers, Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Mauve / StatCVS (running free!)
Here is the latest StatCVS report showing excellent growth for Mauve: http://www.object-refinery.com/classpath/mauve/statcvs/ This report has been generated using JamVM, GNU Classpath, StatCVS, Cairo, the cairo-java bindings and a little bit of custom code - for details see: http://www.object-refinery.com/classpath/statcvs.html I'll be talking about this in an "end-user" talk at FOSDEM, and look forward to seeing some of you there. Regards, Dave
[Bug swing/26033] JTextField: strange delete key behavior
--- Comment #1 from audriusa at bluewin dot ch 2006-01-31 19:51 --- Yes. This is seen in the JTextField demo on our Swing activity board. -- audriusa at bluewin dot ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-01-31 19:51:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26033 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26002] Another regex problem: \p{Nd}
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |0.21 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26002 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: New native layer
On Jan 31, 2006, at 1:00 PM, Roman Kennke wrote: Hi Casey, Am Dienstag, den 31.01.2006, 12:37 -0800 schrieb Casey Marshall: On Jan 31, 2006, at 11:32 AM, Roman Kennke wrote: Hi Brian, hi list, Yea, I think the point for me would be to keep Classpath's java hackers out of the business of writing native code, and especially out of the business of porting native code for such common idioms as generic file operations, network operations, etc. BTW, Torsten, the man who first wrote the target native layer, mostly works on native code and porting of this to platforms you would not dream of. That is arrogant. I'm sure everyone here who hacks on Classpath has worked with interesting technologies, and are all great engineers, each in his own right. So let's stop measuring cocks here, OK? Sorry, I didn't want to sound arrogant or whatnot. I am only a bit upset about this braindead discussion again. I'm sure some of us do appreciate the discussion, and don't find it brain-dead in the least. You have your own goals, and have made up your mind about POSIX and autoconf, that is clear, so you can feel free to ignore this discussion. I get the impression that there is a general opposition against real portability concerns within the GNU (Classpath?) project. Correct me if I am wrong. I think you're mistaken, if you think it is mere opposition. We have, like Per said in another reply, a portability layer already, and it is POSIX. It's an established standard, and it is available on many free (and non-free) platforms today, all of which we desire our code to run on with the highest priority. To put it a little more bluntly, and to paraphrase David Wallace, we can really only love what we value. Portability for the sake of platforms we don't use, or even know the names of, is not something we find immediately valuable. There certainly are parties that have portability demands that go beyong posix. Granted, Aicas is a commercial party and cannot publish every port. There is also Kaffe, which is 100% GPL and now also suggest something similar like the target layer, only somewhat nicer, and again it seems to turn out to be a fight against windmills. I don't get the windmills reference, but I think I get your point. With Kaffe, it isn't completely clear to me what the issues are, and how a native portability layer solves them. But after all, that is what we have the VM interface for and I for myself don't want to discuss C issues anymore and instead concentrate on getting the VM interface into a good shape (it already is IMO, needs some tweaks though) and let people with different opinions on native code fork/implement their own stuff below the VM interface. Yes, that is the best idea, I think. I still want to see a nice POSIXy reference implementation, though, even if it is only for the selfish reason so I can run jamvm on my OS X and GNU/Linux machines to test out code.
Re: New native layer
Per Bothner wrote: Casey Marshall wrote: We have the responsibility, as contributors to a GNU project, to maintain the project for the GNU system. GNU is sorta-POSIX, as are a lot of other interesting platforms, and targeting them earns us, as free software contributors -- not necessarily other groups or companies that want to use Classpath -- a lot. I see these "native portability layers" as being counter to that goal, and they especially don't make sense given that there's no other free implementations for platforms other than what we are targeting. An alternative take with similar conclusion: There is a standard "native portability layer". It is called Posix. There are multiple implementations of this layer available for MS-Windows. Other platforms we are likely to support (such as OS-X) already support Posix. I.e. there is no need for an extra portability layer. Exactly my sentiments (as a bystander in this thread so far) The parts of POSIX that Classpath uses are pretty much exactly those parts that Classpath needs. So why not just implement that subset of POSIX on your obscure platform? As a side-benefit, lots of other stuff might compile and work on your platform then too. Another thing that bugs me is that it's extra work to create a new 'layer' for each platform. Instead, the autoconf system is much more efficient: once you implement a test for whatever non-POSIX thing, that test can work for all platforms that need it, now and in the future. The "layer" idea is too big a level of granularity to be porting at. We should be porting more like at the function call and macro level. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: New native layer
On Tue, 2006-01-31 at 22:00 +0100, Roman Kennke wrote: > I get the impression that there > is a general opposition against real portability concerns within the GNU > (Classpath?) project. Correct me if I am wrong. There certainly are > parties that have portability demands that go beyong posix. Yes. Many parties probably do, or will do eventually. It's in the nature of free software to get ported, somehow, to anything people want to run it on. ;) But I doubt there are many developers inside GNU Classpath as a whole who'd be interested in maintaining non-POSIX code, since most VMs either support only POSIX, POSIX + something special or only something special, so that the set of stuff that's got a fair chance of being communally maintained since it is useful to more than a single VM boils down to POSIX alone. That's pretty much the stuff that has a fair chance of getting love by diffeent VMs in the common tree. So if, theoretically, Kaffe was ported to run on top of Ruby[0] it would make most sense to keep the maintenance & the associated busywork for the Ruby port of GNU Classpath's native libraries in KaffeOnRuby, rather than trying to maintain it inside GNU Classpath. Same if JamVM was ported to 16-bit Minix 2 on Amiga: the necessary changes to the native layer would be too invasive to bother the POSIX-only VMs with, as they'd add some burden without necessary immediate gratification for posix-only VMs. Immediate gratification good, maintenance burden bad. :) I think the hard question is how to make the native layer stuff such that a) most vms can profit from it, in particular when starting from ground up and b) it is easy enough to embrace and extend for those cases where it does not fit well, without forcing one to wholesome fork the native layer, or to maintain the odd, single-VM cases inside GNU Classpath. The answer to a) seems to be POSIX for the reasons given above, and to b) seems to be something like Guilhem's work on the native layer. > Granted, > Aicas is a commercial party and cannot publish every port. There is also > Kaffe, which is 100% GPL and now also suggest something similar like the > target layer, only somewhat nicer, and again it seems to turn out to be > a fight against windmills. A major issue is that for green threads (i.e. jthreads) in Kaffe, we'd have to make sure that we can disable interrupts before invoking a system method, and enable them before we exit again. If we don't do that, than bad things can (and do ;) happen. That's a pretty Kaffe-specific need, though, so it may not make sense to make room for it in GNU Classpath, unless it is accompanied by some other, instant gratification, like looking very much like plain old POSIX. In theory, if we're lucky, Kaffe may also be able to get by using AspectC++[1] or something equivalently weird to weave in the stuff we need for jthreads. In practice, I don't think anyone has done something like that yet, though. ;) cheers, dalibor topic [0] Just imagine the potential for book sales! ;) [1] http://www.aspectc.org/Publications.6.0.html
Re: New native layer
On Jan 31, 2006, at 3:51 PM, Dalibor Topic wrote: On Tue, 2006-01-31 at 22:00 +0100, Roman Kennke wrote: Granted, Aicas is a commercial party and cannot publish every port. There is also Kaffe, which is 100% GPL and now also suggest something similar like the target layer, only somewhat nicer, and again it seems to turn out to be a fight against windmills. A major issue is that for green threads (i.e. jthreads) in Kaffe, we'd have to make sure that we can disable interrupts before invoking a system method, and enable them before we exit again. If we don't do that, than bad things can (and do ;) happen. That's a pretty Kaffe-specific need, though, so it may not make sense to make room for it in GNU Classpath, unless it is accompanied by some other, instant gratification, like looking very much like plain old POSIX. In theory, if we're lucky, Kaffe may also be able to get by using AspectC++[1] or something equivalently weird to weave in the stuff we need for jthreads. In practice, I don't think anyone has done something like that yet, though. ;) Would it help to have a utility function, say as a private function in the JNIEnv, that told the VM that the code was entering or just exited a possibly-blocking system call? Which, in the default implementation for other VMs or threading systems, would be a no-op? E.g.: void EnterSystemCall (JNIEnv *env, void *address); void ExitSystemCall (JNIEnv *env, void *address); This would (I think) be a good place for Kaffe to disable whatever interrupts it had to, and would still be a generic-enough mechanism for a VM to keep track of where the native code is. We would need to find all the right places to call this, but I don't think that's much harder than rewriting everything with wrapper functions, and it would be extensible -- anything added that Kaffe needed to tweak on before calling would be made safe, as long as the usage was consistent.
Re: New native layer
Jikes RVM also does m-to-n threading, so it's there's more than 1 VM that's whacky in this regard. The things we need to do are most likely different than what Kaffe needs to do, but having a chance to inject a VM callback before the thread dives off into a blocking system call is something we would like to be able to do. We have some linux specific hacks (evil with dlopen to intercept poll, select, etc), but it's fragile and doesn't work on other platforms like AIX and OS X that Jikes RVM runs on. --dave > A major issue is that for green threads (i.e. jthreads) in Kaffe, we'd > have to make sure that we can disable interrupts before invoking a > system method, and enable them before we exit again. If we don't do > that, than bad things can (and do ;) happen. > > That's a pretty Kaffe-specific need, though, so it may not make sense to > make room for it in GNU Classpath, unless it is accompanied by some > other, instant gratification, like looking very much like plain old > POSIX. In theory, if we're lucky, Kaffe may also be able to get by using > AspectC++[1] or something equivalently weird to weave in the stuff we > need for jthreads. In practice, I don't think anyone has done something > like that yet, though. ;)
