Yuri Gadow

Greenhorn
+ Follow
since May 08, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Yuri Gadow

I believe Reinhold has solved your problem with java.nio.channels. If you can't wait, you could use Welsh's NBIO. As for trying to solve the problem in place, as it were, my first question is why are you using a high level abstraction (HttpURLConnection) when you need low-level control (DataInputStream and block handling)? I would suggest looking at an alternative method to handle your connections (i.e. directly.) I'm not saying there's not a solution to this, although it is a topic that has been beaten to death by many with no results that don't suck � but you may want to step back a bit and see if you can't get around having the problem in the first place.
22 years ago
Wondering if anyone has implemented a reader/writer monitor with separate mutexs for reading and writing (to restrict notifies to the appropriate group and allow writers to be woken singly.)?
I'm having trouble getting around the fact that a wait only releases the lock on the wait target. Any thoughts?
Probably should be in the JFC/AWT forum. Anyway, as far as I know you will not be able to run an app with heavyweight components without an underlying windowing (not necessarily MS Windows) system. I've not seen a successful installation of the Sun JRE on DOS. There's supposedly a free VM that works with DOS though.
What you want is a decompiler (javap is a disassembler.) Some examples include SourceAgain, Decafe, Mocha, WingDis, etc. If your Servlet came from a JSP, note that many JSP compilers support writing out the Servlet.java separately.
22 years ago
I don't know (so if you figure it out definitively, post it back here). However, I would guess that the iterator approach would be faster, as getting an array from the ArrayList would be a fairly expensive memcopy that would outweight the speed of working directly with an array. In essence, you are trading one checkcast and two invokeinterfaces per element with no duplication of memory (other than local vs. main) for a complete copy op with only one checkcast and a slew of pops and pushes and an iinc (note that to get that copy, a System.arrayCopy would be used - so it's not horrible, but still not great.)
22 years ago
Sure, get rid of the loop -- unless you're worried that the number of minutes in an hour might change in the near future. Would give better performance too.
Run it once, take the output and you'll end up with:
<code>
public static String buildMinute(String name, int minute) {
  return "HTML code here.. <option> etc... <script> document.myForm.mySelect[" + minute + "].selected = true; </script> rest o' html";
}
</code>

Or you could use the ternary operator around all sixty concat options. Regardless, not much point in looping if you know the outcome and know that it cannot change (since -O does nothing, you're loop won't get unrolled unless HotSpot feels like it.)
[This message has been edited by Yuri Gadow (edited July 09, 2001).]
22 years ago
You're right, IMHO. My .02 would be that multiple inheritance is also used to support polymorphism, which multiple interfaces does give you (beyond the single implementation inheritance line.)
Perhaps 'they' were referring to one's ability to have an interface extend multiple super-interfaces - in which case you get reuse of the interface definitions.
22 years ago
Daemon threads will not prevent the VM from exiting. Once all work in non-daemon threads is complete (the runs have returned), the VM will exit - so a daemon thread is most suitable for continuous tasks that support primary functions (like GC, lock sweeping, connection time-outs, etc.)
You could register each thread as you create it, in a Set for instance, and then signal them when it is time to shutdown. The "signal" would simply be a method that sets a flag on the thread that is polled during its run. Alternatively, you can signal with interrupt() and poll with isInterrupted(). The server would be terminated in the same way.
A smaller implementation would be to have the server (which is spawning threads) register itself with the threads before their run starts, so that they can callback to poll a state on the server � depends on your size vs. speed requirements.
Once the thread completes its run, the thread resources (OS level) are deallocated and all that would remain is the reference you hold in the Set � which you will need explicitly clear out � using a weak reference would get you an unreachable thread. Once the branch of instances for a connection is unreachable, it will be eligible for GC.
You might look into handing each item off to asynchronously, to another thread, process or server or some combination thereof. Of course it depends on how much log info you want in a run, in between log writes. If it's going to remain small, a StringBuffer would seem to be the way to go. On the other hand, if performance were top priority, some testing of appending versus pushing Strings onto an array might be in order. Though you might run into problems with GC affecting your timing, depends on the VM and how many. Stopwatches and interns don't do half bad either.
22 years ago
The point is just that you will have to look in the documentation for the specific VM implementation you are using to find out which is used. Most current VM's use native threads, but some provide both if the native implementation is considered flaky. I've never payed any attention to green threads, so I couldn't say if threads can be scheduled across CPU's in "green mode" or not. But it would certainly make sense if that were the case.
Good points. It certainly wouldn't make sense to spawn a single thread and then join it. It would make sense to spawn multiple threads and synchronize on a barrier - which I think is direction Helen is hinting at with thread return values.
Insofar as overriding start(), it certainly isn't a good idea � as you�d basically end up with a Runnable instead of a usable Thread. My (poorly stated) point was that if one were to put in a signature with a return type, it would be start() not run() since the former wraps the latter � but this hardly makes sense to say, so it's a bit of a moot point.
Perhaps I should rephrase the previous post a bit. Simply put, if you merely need synchronized access to a database from a number of Servlets, utilise the database's transaction functionality - not application layer thread logic.
This is going to be OS dependant. I don't know how to accomplish this under windows without using a service, in *nix you'll be looking a variety of options. Suffice it to say, you're going to be depending on the tools provided by the OS to do background processes.
Daemon threads are related to VM shutdown only in that they do not prevent it. In other words, a VM will exit even if there are threads set daemon currently running, where normally it would not if a non-daemon thread was alive. When the VM shuts down, the threads go as well, daemon or otherwise.
Sorry, the links got a bit mangled, let's try that again:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
http://sourceforge.net/projects/jhpc
You cannot change the signature of the start() method, and it is declared as void in both Thread and Runnable � so, no, in the strictest sense, a thread cannot return a value. To get around this, you can use other shared data structures, such as a monitor (an object with methods guarded by synchronized) or a database. Both of the above sites have source code which demonstrates some good solutions for this and quite a few other multithreading issues.
As for controlling concurrent access to a database by your Servlets, that is generally best left to the data logic. If you are using a Commercial Off The Shelf (COTS) database (such as Oracle or SQL Server), it should provide transaction support for you (called via a JDBC API for instance.)
If you do not have access to a transaction manager, then a simple solution would be to apply a synchronized (probably as an alternating reader/writer) Proxy or Adapter pattern to the class(es) that provide you with access to the database in the simple case. Or, if your needs are greater, you may wish to investigate a COTS transaction manager � but you would then need to provide resource manager implementations to work with it.
Is this helping, or am I misunderstanding?

Memory leaks, in the classic sense, don't (shouldn't, rather) occur in Java, since you have no direct way to allocate and (forget to) deallocate memory. There are ways (as always) you can get close though, see Dobb's.
To understand stacks, insofar as they apply to Java, refer to Chapter 3 of the VM Specificaion.
You may also want to pick up a good general science book on compilers or spend some time with a good C/++ book. At the end of the day, it's all the same, just different faces.
22 years ago