java.util.TimerTask

Thu Jun 19 14:35:00 GMT 2003

> public class x
> {
>> public static void main (String s[])
> {
>> Timer mTimer=new Timer();
> QueueTask mQueueTask=new QueueTask();
> //and does something
> mTimer.schedule(mQueueTask,0,100);
> }
> }
>> works correctly AFAICS.

Ok. I'll review if I did something else wrong. It looks as if it is what
I did, but I've probably overlooked something.
> What platform is this? Windows uses WaitForMultipleObjects(), posix
> uses pthread_cond_timedwait(). Neither should eat CPU.

I'm developing on linux. (I'd like to test on win32 too, however):
$ gcj -v
Reading specs from
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Reading specs
from
/usr/local/gcc/3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3/../../../libgcj.sp
ec rename spec lib to liborig
Configured with: ../gcc-3.3/configure --prefix=/usr/local/gcc/3.3
--enable-languages=c,c++,java --enable-threads=posix Thread model: posix
gcc version 3.3
By the way, I've found a way in which "waiting" doesn't consume CPU:
		try
		{
			Thread thisThread = Thread.currentThread();
			while (true)
			{
				thisThread.sleep(10000);
			}
		}
		catch(Exception e) {}
In order to verify, I've looked up in libjava sources if
java.lang.Object.wait(long) and java.lang.Thread.sleep(long) are
implemented in a substantially different way:
natObject.cc, line 219:
switch (_Jv_CondWait (&si->condition,&si->mutex, timeout, nanos))
natThread.cc, line 178 and following:
 natThread *nt = (natThread *) current->data;
 _Jv_MutexLock (&nt->join_mutex);
 _Jv_CondWait (&nt->join_cond, &nt->join_mutex, millis, nanos);
 _Jv_MutexUnlock (&nt->join_mutex);
The only apparent difference between natObject's and natThread's
implementations seem to be that natThread wraps its goodies in a mutex?
I wouldn't like to jumpt to conclusions, but could it be that wrapping
with a mutex prevents CPU consumption anyhow? Could someone who
deeply understands this, pitch in?
Another question, if someone knows something about the subject. I'm
currently using a TimerTask to poll the filesystem. I'd rather,however,
(if possible) plug in to some kind of filesystem notification system...
Linux-only would do. I'm perfectly willing to native wrap stuff into
CNI and delegate this to native methods. Any thoughts?