Java on RedHat Linux 5.2 with glibc-2.0.110
I am trying to install Java v1.1.7-v1a on my system. I get the errors below when I try to run any bins within the package... The run of java -native crashes if any simple app is run similar to the way javac -native crashes. I also included my ldconfig. Does anyone have suggestions as to how to fix this problem? Thanks so much for your time... Ken [root@noel bin]# ./java /usr/lib/jdk-1.1.7/bin/i686/green_threads/java: error in loading shared libraries: /usr/lib/jdk-1.1.7/lib/i686/green_threads/libjava.so: undefined symbol: _dl_symbol_value [root@noel bin]# ./javac /usr/lib/jdk-1.1.7/bin/i686/green_threads/java: error in loading shared libraries: /usr/lib/jdk-1.1.7/lib/i686/green_threads/libjava.so: undefined symbol: _dl_symbol_value [root@noel bin]# ./java -native Usage: java [-options] class where options include: -help print out this message -version print out the build version -v -verbose turn on verbose mode -debugenable remote JAVA debugging -noasyncgcdon't allow asynchronous garbage collection -verbosegcprint a message when garbage collection occurs -noclassgcdisable class garbage collection -cs -checksource check if source is newer when loading classes -ss set the maximum native stack size for any thread -oss set the maximum Java stack size for any thread -ms set the initial Java heap size -mx set the maximum Java heap size -D= set a system property -classpath list directories in which to look for classes -prof[:]output profiling data to ./java.prof or ./ -verify verify all classes when read in -verifyremote verify classes read in over the network [default] -noverify do not verify any class [root@noel bin]# ./javac -native SIGSEGV 11* segmentation violation stackbase=BF7FFBA4, stackpointer=BF7FF460 Full thread dump: NULL (TID:0x404f00b0, sys_thread_t:0x81989b8, state:R, thread_t: t@1026, sp:0x0 threadID:0x5583, stack_base:0xbf7ffba4, stack_size:0x20) prio=5 *current thread* java.lang.System.nullInputStream(System.java) java.lang.System.(System.java) java.lang.String.getChars(String.java) java.lang.StringBuffer.append(StringBuffer.java) java.lang.StringBuffer.(StringBuffer.java) java.lang.Thread.(Thread.java) Monitor Cache Dump: java.lang.Class@1078919256/1081019536: owner NULL (0x81989b8, 1 entry) java.lang.StringBuffer@1078919528/1081019424: owner NULL (0x81989b8, 1 entry) Registered Monitor Dump: Thread queue lock: Name and type hash table lock: String intern lock: JNI pinning lock: JNI global reference lock: BinClass lock: Class loading lock: Java stack lock: Code rewrite lock: Heap lock: Has finalization queue lock: Finalize me queue lock: Monitor registry: owner NULL (0x81989b8, 1 entry) ldconfig: version 970402 /usr/i486-linuxaout/lib: libvga.so.1 => libvga.so.1.2.7 libtk.so.3 => libtk.so.3.1.1 libtcl.so.3 => libtcl.so.3.1 libm.so.4 => libm.so.4.6.27 libdb.so.1 => libdb.so.1.85.1 libcurses.so.0 => libcurses.so.0.1.2 libc.so.4 => libc.so.4.7.2 libXt.so.6 => libXt.so.6.0 libXt.so.3 => libXt.so.3.1.0 libXpm.so.4 => libXpm.so.4.2 libXaw.so.6 => libXaw.so.6.0 libXaw.so.3 => libXaw.so.3.1.0 libXIE.so.6 => libXIE.so.6.0 libX11.so.6 => libX11.so.6.0 libX11.so.3 => libX11.so.3.1.0 /usr/lib: libnewt.so.0.30 => libnewt.so.0.30 libpanel.so.3.0 => libpanel.so.1.9.9e libncurses.so.3.0 => libncurses.so.1.9.9e libmenu.so.3.0 => libmenu.so.1.9.9e libform.so.3.0 => libform.so.1.9.9e libesddsp.so.0 => libesddsp.so.0.2.7 libmico2.0.5.so => libmico2.0.5.so libaudiofile.so.0 => libaudiofile.so.0.0.0 libghttp.so.0 => libghttp.so.0.99.0 libjpeg.so.62 => libjpeg.so.62.0.0 libsnmp.so.0 => libsnmp.so.0.3.5.3 libtixsam4.1.8.0.so => libtixsam4.1.8.0.so libtix4.1.8.0.so => libtix4.1.8.0.so libtk8.0.so => libtk8.0.so libtkx8.0.3.so => libtkx8.0.3.so libtclx8.0.3.so => libtclx8.0.3.so libtcl8.0.so => libtcl8.0.so libvgagl.so.1 => libvgagl.so.1.3.0 libvga.so.1 => libvga.so.1.3.0 libreadline.so.3 => libreadline.so.3.0 libhistory.so.3 => libhistory.so.3.0
Source code for JRE
Sir/Madam, I want JRE for linux and I downloaded the files from your website .I also want the source code of JRe.Can you please help me where i can find the same or if it is there in the file i downloaded kindly give me the location.I would be very much obliged if you do me this favour. Thanking you, M.Swarnalatha.
Flash Disk
Hallo, I heard, that on your maillist there is a discussion about RTLinux on a flash disk. I think the article was from James Cassidy. Please can you tell me, where I can get more info about putting a tiny RTLinux on a flash disk. Thank you very much in advance. Christian Tannert Krones AG Boehmerwaldstrasse 5 93068 Neutraubling Tel.: (0 94 01) 70 - 0 Fax: (0 94 01) 70 - 24 88
Re: Green/Native threads
>All that other discussion about Linux process table slots and >implementation details is interesting, but not really relevant to the >distinction between light and heavy. There's one important difference - you can only have as many threads in Linux as you can have processes. And there's a suprisingly low upper limit on that, something like 256? I'm one of those wacky people who likes the idea of writing programs with thousands of threads (most stopped most of the time), so that's a bit of a drag. I'm curious how Java thread priorities are layered on top of LinuxThreads.. When a thread of high priority becomes runnable, is a SIGSTOP sent to all lower priority threads to make them stop until the high priority thread finishes? I sure wish Java's threading model was different. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: jdk1.2 class lib on jdk1.1 jvm?
At 12:07 AM +0100 2/8/99, Logi Ragnarsson wrote: >in the short term all I really need is the collections API. There is a version for java 1.1: http://www.javasoft.com/beans/infobus/index.html#COLLECTIONS Cheers, Paul
Re: Web site dead?!?/Java 2
At 12:27 AM +0100 2/8/99, Joachim Breuer wrote: >Hello! > >As can be seen on http://www.blackdown.org/java-linux/info.html, your >web site has last been touched on 98/12/17 with the remark that >1.2/Java2 is sorta running and to be expected in at most one month. Did you actually check the page? The JDK 1.2 info was last modified Mon, Feb 1, 1999 12:30:11 AM GMT http://www.blackdown.org/java-linux/ports.html#jdk1.2 Kevin B. Hendricks also posted a status report last Wednesday: >Date: Wed, 3 Feb 1999 19:15:00 -0500 >To: [EMAIL PROTECTED] >From: "Kevin B. Hendricks" <[EMAIL PROTECTED]> >Subject: Another JDK 1.2 Status Report Cheers, Paul
Re: Green/Native threads
> There's one important difference - you can only have as many threads > in Linux as you can have processes. And there's a suprisingly low > upper limit on that, something like 256? I'm one of those wacky people > who likes the idea of writing programs with thousands of threads (most > stopped most of the time), so that's a bit of a drag. is there a fairly painless way to increase the process limit? pete
Re: Java on RedHat Linux 5.2 with glibc-2.0.110
Your problem is related to the version of glibc you are using. The JDK 1.1.7 uses an internal symbol, _dl_symbol_value, which was present in glibc 2.0 but is no longer in glibc 2.1, thus the undefined symbol error. I believe JDK 1.1.6 does not use this symbol and should be fine, although I have not checked it myself yet. The next JDK release (whether 1.2 or an upgrade of 1.1.7) should have this fixed. BTW, glibc 2.1 has been officially released, so you can upgrade it (although I doubt that will solve your problem here). And lo, the chronicles report that Kenneth J. Baker spake thusly unto the masses: > > > I am trying to install Java v1.1.7-v1a on my system. I get the errors > below when I try to run any bins within the package... The run of java > -native crashes if any simple app is run similar to the way javac -native > crashes. I also included my ldconfig. Does anyone have suggestions as > to how to fix this problem? > > Thanks so much for your time... > > Ken > -- ¤¤ | Aaron Gaudio mailto:[EMAIL PROTECTED] | |http://www.rit.edu/~adg1653/| ¤¤ | "The fool finds ignorance all around him. | | The wise man finds ignorance within." | ¤¤ Use of any of my email addresses is subject to the terms found at http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you agree to be bound by the terms therein.
Re: Green/Native threads
Nathan Meyers wrote: > > I think a lot of people are getting hung up on the notion of lightweight > vs heavyweight processes. Here's the quick definition of the > differences, followed by an explanation of why it's not really relevant > to this discussion: > > - Heavyweight processes run in separate address spaces > - Lightweight processes run in the same address space > > The added weight of heavyweight processes come from the system resources > consumed by more real and virtual memory -- that's what's meant by > "lightweight" vs "heavyweight". When apps start to get big and flog > memory (especially if they flog memory in ways that stress cache and > VM), the light vs heavy distinction really starts to matter. All that > other discussion about Linux process table slots and implementation > details is interesting, but not really relevant to the distinction > between light and heavy. > This was a really relevant piece of info and brings us to what I think is the point of the discussion ;-} > > I'll bet that it wouldn't take a lot of effort to write two benchmarks, > one conclusively showing that green threads are faster, and the other > doing the same for kernel threads. I do believe that execution speed is not always the critical factor in threading. Concurrency and system resources manipulation is the issue raised here. What I believe was that green threads (I used to know them as user space threads) fail to provide with real concurrency when there are computationally heavy operations involved, and you do not provide with an explicit (simple terms: yield by time to time) or implicit (eg listening for sockets) scheduling mechanism. My main concern is that I (and many others as I understand) usually fire up threads left and right to do the computation (and sometimes use some CPU time consuming loops for heavy computation). What I have observed is that concurrency breaks, and degrades into a form of sequential execution (which is not exctly the desired effect) - not to mention GUI manipulation glitches, if they work at all. But it is not a right thing to bring the system kernel to its limit by firing up threads for computation, and this is how I understand the difference betwen threads and processes, and the distinction between light and heavy. It would really be a sad think if linux threads are not really light (but absolutely normal processes that don't even share the same address space)and bring the kernel to its process limit. > > > Here are my (admittedly personal) reasons you'd want to use kernel > threads: > > 1) Take advantage of multiprocessors if you've got them java is supposed to know nothing of SMP ;-} (but it helps if present) > > 2) Native-thread preemption is more likely to happen in a way that > improves interactivity (but don't bet product sales on it!) > 3) Native-thread preemption is likely to stress-test your program more > effectively > > Here are the reasons you wouldn't: > > 1) They don't work yet :-) sad to say, but it is true... > > 2) Your code is dependent on the gentle, friendly preemption (or > non-preemption) you get from green threads and is broken by kernel > threads > I deduce that we shouldn't relly on the VM to do the scheduling, since it is not known if it will. (and this breaks another myth: in java, even threads are easy to handle ;-} ) thanx for your attention, Dimitris
Re: Green/Native threads
Nelson Minar wrote: > >All that other discussion about Linux process table slots and > >implementation details is interesting, but not really relevant to the > >distinction between light and heavy. > > There's one important difference - you can only have as many threads > in Linux as you can have processes. And there's a suprisingly low > upper limit on that, something like 256? oops. Aren't we supposed to be able to overcome this limitation? It is really sad to have this limitation hanging as a big dark cloud above us. ;-} I believe that this limitation is not the case in some other "massively inferior" OSes like NT. I would also like to augment that NT threads appear to share the same address space, except for a private stack. For example, in order to safely access the heap, you need to wrap your code into HeapLock and HeapUnLock sys calls. And not to mention that there is no obvious limit (I am sure it is hidden somewhere, burried so deeply that you'll probably get the blue screen of death when you reach it) in the number of active threads ( OK, this is really off-topic) > > I'm curious how Java thread priorities are layered on top of > LinuxThreads.. When a thread of high priority becomes runnable, is a > SIGSTOP sent to all lower priority threads to make them stop until the > high priority thread finishes? > This is another interesting subject I would also like to know about. Dimitris
Re: Flash Disk
I'm this you got the wrong try the real-time linux list to subscribe or get more information --- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl " | mail [EMAIL PROTECTED] For more information on Real-Time Linux see: http://www.rtlinux.org/~rtlinux/ Cheers Chris Christian Tannert wrote: Hallo, I heard, that on your maillist there is a discussion about RTLinux on a flash disk. I think the article was from James Cassidy. Please can you tell me, where I can get more info about putting a tiny RTLinux on a flash disk. Thank you very much in advance. Christian Tannert Krones AG Boehmerwaldstrasse 5 93068 Neutraubling Tel.: (0 94 01) 70 - 0 Fax: (0 94 01) 70 - 24 88
Helping out with JDK1.2?
Judging from the web-page you've had a lot of people bugging you about JDK1.2. I was wondering if there's anything I can do to speed the process of delivery/porting up (other than stop emailing the porting team! :) ? Cheers, Dan. -- ++ | Dan Creswell Email: [EMAIL PROTECTED] | | Senior Analyst Programmer Tel: 01483 447828 | | M.A.C. UK Ltd. | | PGP Finger Print: 5B 86 BC 5C 21 4D 04 4E 2D 05 21 F0 B0 AE 7E 9B | ++
Re: Green/Native threads
Michael Sinz wrote: > > >Aren't we supposed to be able to overcome this limitation? It is really > >sad to have this limitation hanging as a big dark cloud above us. ;-} > >I believe that this limitation is not the case in some other "massively > >inferior" OSes like NT. I would also like to augment that NT threads > >appear to share the same address space, except for a private stack. > > Well, NT does have a thread limit. And it is system global. Depending > on some registry things it could be a total of 512 threads or 128 threads > or 1024 threads or... This limit is for all threads in all processes. > So, if one processes uses 500 threads there are only 12 left for the whole > rest of the system! > This is what I meant by "I am sure it is hidden somewhere, burried so deeply that you'll probably get the blue screen of death when you reach it". No OS is known to behave well in that limit, imagine moft's OSes > > It is a shame that operating systems have such limits in the core rather > than just limits based on available RAM/VM space or CPU power or... > > The problem is that things get tricky if you do that in threads and have > shared memory (including access to autovariables, which means shared > stack address space) and you have automatic stack address space extension > since you need to partition out your virtual address space into the > stack spaces... A generally ugly problem which gets even worse if you > suddenly add twenty or two hundred threads to a process. > And since we (at least me) are not kernel programmers we should probably not blame those people for not being able to handle this *bad* problem in a perfect fashion. > > If stack space had to be defined by each thread, you can then be just > limited by the total of 2gig or 3gig or 4gig of virtual address space > for a process (which would mean that doing a large number of threads > may end up with some problems with stack space for all of them, but > the number would have to be rather large even if each thread needed > 500K of stack!) > I believe that most systems have at least some 512M available for swaping, not to mention a server that it is most likely to have a large number of threads running in this ideal environment. (I should expect the virutal addressing space used to the limit in such a case) Dimitris
Re: Java on RedHat Linux 5.2 with glibc-2.0.110
> Aaron Gaudio writes: > Your problem is related to the version of glibc you are using. The JDK > 1.1.7 uses an internal symbol, _dl_symbol_value, which was present in > glibc 2.0 but is no longer in glibc 2.1, thus the undefined symbol error. > I believe JDK 1.1.6 does not use this symbol and should be fine, although > I have not checked it myself yet. The next JDK release (whether 1.2 or > an upgrade of 1.1.7) should have this fixed. > BTW, glibc 2.1 has been officially released, so you can upgrade it > (although I doubt that will solve your problem here). glibc 2.1 doesn't fix that problem[1] - and I've been also unsuccessful trying JDK 1.1.6 with glibc 2.1 :-(. Andreas Footnotes: [1] since the problem is in JDK - otherwise glibc 2.1 contains a number of fixes;-) -- Andreas Jaeger [EMAIL PROTECTED][EMAIL PROTECTED] for pgp-key finger [EMAIL PROTECTED]
Re: Green/Native threads
Nelson Minar wrote: > > >All that other discussion about Linux process table slots and > >implementation details is interesting, but not really relevant to the > >distinction between light and heavy. > > There's one important difference - you can only have as many threads > in Linux as you can have processes. And there's a suprisingly low > upper limit on that, something like 256? I'm one of those wacky people > who likes the idea of writing programs with thousands of threads (most > stopped most of the time), so that's a bit of a drag. I hope I didn't imply that the process table slots are a non-issue... just that they're not central to the distinction between light- and heavy-weight. But I'm always curious about "wacky people" who like to use thousands of threads (or tons of memory or zillions of levels of recursion, etc.). Is that approach fundamental to solving the problem efficiently, or do you use it because it's convenient and/or cool? Nathan Meyers [EMAIL PROTECTED]
RE: Green/Native threads
Nathan Meyers wrote, > But I'm always curious about "wacky people" who like > to use thousands of threads (or tons of memory or > zillions of levels of recursion, etc.). Is that > approach fundamental to solving the problem > efficiently, or do you use it because it's convenient > and/or cool? Err ... is that a serious question? Suppose I'm writing an HTTP server, and my architecture comes out cleanest if I can assign one thread per request, and I want to be able to support more than 256 concurrent requests. For "HTTP server" feel free to substitute anything comparable. Within the terms in which you phrased the question I guess the answer has to be "because it's convenient", but I think it goes a bit deeper than that. Cheers, Miles -- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)181 410 2230 London, W6 0LJ [EMAIL PROTECTED] England
Re: Green/Native threads
A bit more info on thread limits.. Linux 2.0 defines NR_TASKS in /usr/src/linux/include/linux/tasks.h. The default is 512, but then there's MAX_TASKS_PER_USER which is defined as NR_TASKS/2. So if I understand right, that means that a Java process using native threads is limited to 256 threads in the default kernel. It's possible that boosting NR_TASKS up and recompiling the kernel will Just Work, but I don't know. I also don't know the implications on kernel memory used or scheduler performance. The reason kernels have compiled-in limits like this is it greatly simplifies and speeds up the scheduler. Dealing with dynamic memory structures is a mess, particularly if you can't rely on the VM system in the kernel to manage your memory. Most Unix kernels I know have similar limits. Another issue is pre-emptive multitasking. Java does *not* guarantee pre-emptive multitasking, period. So in some sense, a correct Java application should not care whether it's green threads or native threads. Personally, I think it'd be nifty if Java/Linux were higher quality than other Java implementations, and had nicer threading. The VM to beat here is Windows NT, at least under Java 1.1. The problem is, what improvements should one make? It's not clear that guaranteeing preemption is the best thing, since Java is speced to not guarantee it itself. Personally, I'd like to see thread creation and switching time be optimized heavily, and secondarily to make sure that Java/Linux can deal with a whole lot of threads at once. Another angle to pursue is to follow what the Java Real Time Extension people are up to; they will presumably need to augment the Java threading model, and if Linux can track that we might have a leg up. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Green/Native threads
Nathan Meyers asks: >But I'm always curious about "wacky people" who like to use thousands >of threads (or tons of memory or zillions of levels of recursion, >etc.). Is that approach fundamental to solving the problem >efficiently, or do you use it because it's convenient and/or cool? A bit of both. My work in Java centers on building distributed agent systems. Roughly, for me an agent is exactly a Java object with its own thread. (An "Actor"). So my system can only support as many agents as there are threads available. That's a fundamental requirement of my model of computation, and I'd really rather my OS supported lots of threads. Typically, though, I have less than 50 agents in one process, so it's not a big problem. The other reason I need lots of threads is to simulate asynchronous messaging. When an agent calls a method on a remote agent (via RMI), they don't necessarily want to wait for the remote agent to return. Ie: I want some method calls to be asynchronous. The naive way to implement that is to fork two threads per message call - one for executing the call asynchronously, and one (that mostly sleeps) to implement a timeout on the call. There are more efficient ways to implement these things - you can do some thread pooling for message execution, and if you're clever you can have one thread for the whole VM managing timeouts. But they're a pain, and I'd dearly love it if the VM could just support the simple implementation directly. [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/
Re: Green/Native threads
At 12:09 PM -0500 2/8/99, Nelson Minar wrote: >A bit more info on thread limits.. Linux 2.0 defines NR_TASKS in >/usr/src/linux/include/linux/tasks.h. The default is 512, but then >there's MAX_TASKS_PER_USER which is defined as NR_TASKS/2. So if I >understand right, that means that a Java process using native threads >is limited to 256 threads in the default kernel. It's possible that >boosting NR_TASKS up and recompiling the kernel will Just Work, but I >don't know. I also don't know the implications on kernel memory used >or scheduler performance. In Linux 2.2.1, NR_TASKS is 512 and the comment said "On x86 Max 4092, or 4090 w/APM configured." So i suppose up to 4092 tasks, assume you have enough memory, is just a recompile away. Cheers, Paul
oops
TYA:EXCEPTIONS_BY_SIGNALS problem *** panic: TYA:EXCEPTIONS_BY_SIGNALS problem TYA: Signal 6, returning to default handler; SIGABRT 6* abort (generated by abort(3) routine) stackbase=0xb580, stackpointer=0xb480 Full thread dump: "Finalizer thread" (TID:0x4066d210, sys_thread_t:0x413b1e0c, state:R) prio=1 "Async Garbage Collector" (TID:0x4066d258, sys_thread_t:0x41390e0c, state:R) prio=1 "Idle thread" (TID:0x4066d2a0, sys_thread_t:0x4136fe0c, state:R) prio=0 "Clock" (TID:0x4066d088, sys_thread_t:0x4134ee0c, state:CW) prio=12 "main" (TID:0x4066d0b0, sys_thread_t:0x81d2888, state:R) prio=5 *current thread* test.SegZip.doCompress(Compiled Code) test.SegZip.main(Compiled Code) Monitor Cache Dump: Registered Monitor Dump: Thread queue lock: Name and type hash table lock: String intern lock: JNI pinning lock: JNI global reference lock: BinClass lock: Class loading lock: Java stack lock: Code rewrite lock: Heap lock: Has finalization queue lock: Finalize me queue lock: Dynamic loading lock: Monitor IO lock: Child death monitor: Event monitor: I/O monitor: Alarm monitor: Waiting to be notified: "Clock" (0x4134ee0c) Monitor registry: owner "main" (0x81d2888, 1 entry) Thread Alarm Q: Aborted (core dumped) Any ideas welcome...
Re: Green/Native threads
Nathan Meyers wrote: > But I'm always curious about "wacky people" who like to > use thousands of threads (or tons of memory or zillions of levels of > recursion, etc.). Is that approach fundamental to solving the problem > efficiently, or do you use it because it's convenient and/or cool? > Sometimes the model involved is recursive/concurrent by definition, and a recursive/concurrent implementation is the cleanest way to implement it. What are we supposed to do in such cases? Perplex the situation badly in order to avoid using lots of threads? There are cases you simply can't do so. Dimitris
Re: Green/Native threads
> Nelson Minar writes: Nelson> I'm curious how Java thread priorities are layered on top Nelson> of LinuxThreads.. When a thread of high priority becomes Nelson> runnable, is a SIGSTOP sent to all lower priority threads Nelson> to make them stop until the high priority thread finishes? Since we use LinuxThreads and SCHED_OTHER, 1.2 native threads ignores Java thread priorities (that is valid with respect to the JLS). 1.1.7 used a trick to allow reducing a thread's priority. Juergen -- Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V Baroper Strasse 301, D-44221 Dortmund, Germany Phone: ++49 231/755-5806, Fax: ++49 231/755-5802
Re: Green/Native threads
Dimitris Vyzovitis wrote: > Nathan Meyers wrote: > > > But I'm always curious about "wacky people" who like to > > use thousands of threads (or tons of memory or zillions of levels of > > recursion, etc.). Is that approach fundamental to solving the problem > > efficiently, or do you use it because it's convenient and/or cool? > > > > Sometimes the model involved is recursive/concurrent by definition, and a > recursive/concurrent implementation is the cleanest way to implement it. > What are we supposed to do in such cases? Perplex the situation badly in > order to avoid using lots of threads? > > There are cases you simply can't do so. I certainly touched off a firestorm with my question :-). Probably made a few enemies in the process, but I hope not. Since this has drifted pretty far off-topic for Java/Linux, I think I'll keep quiet after this response. There is rarely a single way to solve a problem, and reality dictates that it is sometimes necessary to make concessions to the architectural limitations you're working under. Java does a lovely job of abstracting out architectural differences, but that isn't always consistent with creating a solution that works or performs well in the real world. Consider the humble act of traversing a binary tree. That lends itself naturally to recursion. But you can also do it iteratively if you're willing to add a couple more fields to each node. If your stack is small, that might make the difference between working and not working. Crude, as they say, but effective. Nathan Meyers [EMAIL PROTECTED]
Re: Green/Native threads
Dimitris Vyzovitis wrote: > Nathan Meyers wrote: > > > But I'm always curious about "wacky people" who like to > > use thousands of threads (or tons of memory or zillions of levels of > > recursion, etc.). Is that approach fundamental to solving the problem > > efficiently, or do you use it because it's convenient and/or cool? > > > > Sometimes the model involved is recursive/concurrent by definition, and a > recursive/concurrent implementation is the cleanest way to implement it. > What are we supposed to do in such cases? Perplex the situation badly in > order to avoid using lots of threads? > > There are cases you simply can't do so. I certainly touched off a firestorm with my question :-). Probably made a few enemies in the process, but I hope not. Since this has drifted pretty far off-topic for Java/Linux, I think I'll keep quiet after this response. There is rarely a single way to solve a problem, and reality dictates that it is sometimes necessary to make concessions to the architectural limitations you're working under. Java does a lovely job of abstracting out architectural differences, but that isn't always consistent with creating a solution that works or performs well in the real world. Consider the humble act of traversing a binary tree. That lends itself naturally to recursion. But you can also do it iteratively if you're willing to add a couple more fields to each node. If your stack is small, that might make the difference between working and not working. Crude, as they say, but effective. Nathan Meyers [EMAIL PROTECTED]
Re: oops - solved
Dimitris Vyzovitis wrote: TYA:EXCEPTIONS_BY_SIGNALS problem *** panic: TYA:EXCEPTIONS_BY_SIGNALS problem // lots of stuff It proved that it was just an ugly way to say "NullPointerException". Sorry for any distress. Dimitris
IBM to deploy LinuxPPC on RS6000 servers...
Wow! Have a gander at http://www.techweb.com/se/directlink.cgi?CRN19990208S0005 Basically, IBM has been very impressed with the way that Linux has kicked NT butt all-over the server market and is planing to bundle LinuxPPC on their RS6000 servers! It looks as though Big Blue is taking advantage of the delayed deployment of... Windows 2000! Wow! -- /\ | Jerry McBride | | [EMAIL PROTECTED] | \/
