Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-21 Thread Leo Li

Hi, all
I will volunteer to generate the document and add it to the website.


On 9/14/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


So - no matter what happens w/ the docs, we do need this in the code...

geir


Tim Ellison wrote:
 yep -- that's what I meant.  The on-line doc should be generated from
 the code comments as it is today.

 Regards,
 Tim

 Morozova, Nadezhda wrote:
 As I got it, the referenced documentation is created from code already,
 so I don't quite get Geir's comment ;(
 Anyway, I agree that keeping docs up-to-date is important. Do you think
 we can ask the community to update comments with the code changes? This
 way, the docs will never be out-of-sync. And those reading the code
will
 have a better understanding of what it does.

 Best regards,
 Nadya Morozova


 -Original Message-
 From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
 Sent: Thursday, September 14, 2006 5:36 PM
 To: harmony-dev@incubator.apache.org
 Subject: Re: [classlib][luni] Put setInterruptAction() in our
j.l.Thread
 stub?

 true, but there's no reason why this couldn't be in the code too...

 geir

 Tim Ellison wrote:
 Our VM interface documentation[1] is drifting out of sync with code
 changes.  If anyone has time to refresh it, with help from the dev
 list,
 that would be a very valuable task.  We should ensure that VM writers
 understand how to get the harmony class library code working with
 their VM.
 [1] amongst others,


http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
 oc/kernel_doc/html/index.html?view=co
 Regards,
 Tim


 Oliver Deakin wrote:
 Geir Magnusson Jr. wrote:
 This came up in another thread.

 Currently, java.nio.channels.spi.AbstractInterruptibleChannel
 depends
 on there being a setInterruptAction() method on java.lang.Thread.

 I certainly think that this kind of thing should be documented, so
 the
 question - should we add this to our Thread stub class?
 Yes we should - I didn't realise initially that this method was being
 used (since it was private).
 Now we know it's in use in AbstractInterruptibleChannel, we'd better
 put
 some doc in for future
 kernel writers. Can someone just bring back the original comments and
 method stub that was
 there?

 Regards,
 Oliver

 geir


 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Leo Li
China Software Development Lab, IBM


Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-14 Thread Tim Ellison
Our VM interface documentation[1] is drifting out of sync with code
changes.  If anyone has time to refresh it, with help from the dev list,
that would be a very valuable task.  We should ensure that VM writers
understand how to get the harmony class library code working with their VM.

[1] amongst others,
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html?view=co

Regards,
Tim


Oliver Deakin wrote:
 
 
 Geir Magnusson Jr. wrote:
 This came up in another thread.

 Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends
 on there being a setInterruptAction() method on java.lang.Thread.

 I certainly think that this kind of thing should be documented, so the
 question - should we add this to our Thread stub class?
 
 Yes we should - I didn't realise initially that this method was being
 used (since it was private).
 Now we know it's in use in AbstractInterruptibleChannel, we'd better put
 some doc in for future
 kernel writers. Can someone just bring back the original comments and
 method stub that was
 there?
 
 Regards,
 Oliver
 

 geir

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-14 Thread Geir Magnusson Jr.

true, but there's no reason why this couldn't be in the code too...

geir

Tim Ellison wrote:

Our VM interface documentation[1] is drifting out of sync with code
changes.  If anyone has time to refresh it, with help from the dev list,
that would be a very valuable task.  We should ensure that VM writers
understand how to get the harmony class library code working with their VM.

[1] amongst others,
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html?view=co

Regards,
Tim


Oliver Deakin wrote:


Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends
on there being a setInterruptAction() method on java.lang.Thread.

I certainly think that this kind of thing should be documented, so the
question - should we add this to our Thread stub class?

Yes we should - I didn't realise initially that this method was being
used (since it was private).
Now we know it's in use in AbstractInterruptibleChannel, we'd better put
some doc in for future
kernel writers. Can someone just bring back the original comments and
method stub that was
there?

Regards,
Oliver


geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-14 Thread Morozova, Nadezhda
As I got it, the referenced documentation is created from code already,
so I don't quite get Geir's comment ;( 
Anyway, I agree that keeping docs up-to-date is important. Do you think
we can ask the community to update comments with the code changes? This
way, the docs will never be out-of-sync. And those reading the code will
have a better understanding of what it does.

Best regards, 
Nadya Morozova
 

-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 14, 2006 5:36 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread
stub?

true, but there's no reason why this couldn't be in the code too...

geir

Tim Ellison wrote:
 Our VM interface documentation[1] is drifting out of sync with code
 changes.  If anyone has time to refresh it, with help from the dev
list,
 that would be a very valuable task.  We should ensure that VM writers
 understand how to get the harmony class library code working with
their VM.
 
 [1] amongst others,

http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/kernel_doc/html/index.html?view=co
 
 Regards,
 Tim
 
 
 Oliver Deakin wrote:

 Geir Magnusson Jr. wrote:
 This came up in another thread.

 Currently, java.nio.channels.spi.AbstractInterruptibleChannel
depends
 on there being a setInterruptAction() method on java.lang.Thread.

 I certainly think that this kind of thing should be documented, so
the
 question - should we add this to our Thread stub class?
 Yes we should - I didn't realise initially that this method was being
 used (since it was private).
 Now we know it's in use in AbstractInterruptibleChannel, we'd better
put
 some doc in for future
 kernel writers. Can someone just bring back the original comments and
 method stub that was
 there?

 Regards,
 Oliver

 geir


-
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
[EMAIL PROTECTED]


 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-14 Thread Geir Magnusson Jr.



Morozova, Nadezhda wrote:

As I got it, the referenced documentation is created from code already,
so I don't quite get Geir's comment ;( 


Because some docs don't come from code.  I'd prefer that for code-like 
things (like expectations we have for implementers of kernel classes) 
that at least our stubs have the right information in them.



Anyway, I agree that keeping docs up-to-date is important. Do you think
we can ask the community to update comments with the code changes?


What do you mean?

 This

way, the docs will never be out-of-sync. And those reading the code will
have a better understanding of what it does.




Best regards, 
Nadya Morozova
 


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 14, 2006 5:36 PM

To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread
stub?

true, but there's no reason why this couldn't be in the code too...

geir

Tim Ellison wrote:

Our VM interface documentation[1] is drifting out of sync with code
changes.  If anyone has time to refresh it, with help from the dev

list,

that would be a very valuable task.  We should ensure that VM writers
understand how to get the harmony class library code working with

their VM.

[1] amongst others,


http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/kernel_doc/html/index.html?view=co

Regards,
Tim


Oliver Deakin wrote:

Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel

depends

on there being a setInterruptAction() method on java.lang.Thread.

I certainly think that this kind of thing should be documented, so

the

question - should we add this to our Thread stub class?

Yes we should - I didn't realise initially that this method was being
used (since it was private).
Now we know it's in use in AbstractInterruptibleChannel, we'd better

put

some doc in for future
kernel writers. Can someone just bring back the original comments and
method stub that was
there?

Regards,
Oliver


geir



-

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:

[EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-14 Thread Tim Ellison
yep -- that's what I meant.  The on-line doc should be generated from
the code comments as it is today.

Regards,
Tim

Morozova, Nadezhda wrote:
 As I got it, the referenced documentation is created from code already,
 so I don't quite get Geir's comment ;( 
 Anyway, I agree that keeping docs up-to-date is important. Do you think
 we can ask the community to update comments with the code changes? This
 way, the docs will never be out-of-sync. And those reading the code will
 have a better understanding of what it does.
 
 Best regards, 
 Nadya Morozova
  
 
 -Original Message-
 From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, September 14, 2006 5:36 PM
 To: harmony-dev@incubator.apache.org
 Subject: Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread
 stub?
 
 true, but there's no reason why this couldn't be in the code too...
 
 geir
 
 Tim Ellison wrote:
 Our VM interface documentation[1] is drifting out of sync with code
 changes.  If anyone has time to refresh it, with help from the dev
 list,
 that would be a very valuable task.  We should ensure that VM writers
 understand how to get the harmony class library code working with
 their VM.
 [1] amongst others,

 http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
 oc/kernel_doc/html/index.html?view=co
 Regards,
 Tim


 Oliver Deakin wrote:
 Geir Magnusson Jr. wrote:
 This came up in another thread.

 Currently, java.nio.channels.spi.AbstractInterruptibleChannel
 depends
 on there being a setInterruptAction() method on java.lang.Thread.

 I certainly think that this kind of thing should be documented, so
 the
 question - should we add this to our Thread stub class?
 Yes we should - I didn't realise initially that this method was being
 used (since it was private).
 Now we know it's in use in AbstractInterruptibleChannel, we'd better
 put
 some doc in for future
 kernel writers. Can someone just bring back the original comments and
 method stub that was
 there?

 Regards,
 Oliver

 geir


 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]

 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-14 Thread Geir Magnusson Jr.

So - no matter what happens w/ the docs, we do need this in the code...

geir


Tim Ellison wrote:

yep -- that's what I meant.  The on-line doc should be generated from
the code comments as it is today.

Regards,
Tim

Morozova, Nadezhda wrote:

As I got it, the referenced documentation is created from code already,
so I don't quite get Geir's comment ;( 
Anyway, I agree that keeping docs up-to-date is important. Do you think

we can ask the community to update comments with the code changes? This
way, the docs will never be out-of-sync. And those reading the code will
have a better understanding of what it does.

Best regards, 
Nadya Morozova
 


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 14, 2006 5:36 PM

To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread
stub?

true, but there's no reason why this couldn't be in the code too...

geir

Tim Ellison wrote:

Our VM interface documentation[1] is drifting out of sync with code
changes.  If anyone has time to refresh it, with help from the dev

list,

that would be a very valuable task.  We should ensure that VM writers
understand how to get the harmony class library code working with

their VM.

[1] amongst others,


http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/d
oc/kernel_doc/html/index.html?view=co

Regards,
Tim


Oliver Deakin wrote:

Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel

depends

on there being a setInterruptAction() method on java.lang.Thread.

I certainly think that this kind of thing should be documented, so

the

question - should we add this to our Thread stub class?

Yes we should - I didn't realise initially that this method was being
used (since it was private).
Now we know it's in use in AbstractInterruptibleChannel, we'd better

put

some doc in for future
kernel writers. Can someone just bring back the original comments and
method stub that was
there?

Regards,
Oliver


geir



-

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:

[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-13 Thread Oliver Deakin



Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends 
on there being a setInterruptAction() method on java.lang.Thread.


I certainly think that this kind of thing should be documented, so the 
question - should we add this to our Thread stub class?


Yes we should - I didn't realise initially that this method was being 
used (since it was private).
Now we know it's in use in AbstractInterruptibleChannel, we'd better put 
some doc in for future
kernel writers. Can someone just bring back the original comments and 
method stub that was

there?

Regards,
Oliver



geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-10 Thread Jimmy, Jing Lv

Gregory Shimansky wrote:

On Friday 08 September 2006 06:03 Jimmy, Jing Lv wrote:

Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on
there being a setInterruptAction() method on java.lang.Thread.

I certainly think that this kind of thing should be documented, so the
question - should we add this to our Thread stub class?

Yes, the VMs whose Thread do not know how to interrupt a certain
understratum blocking I/O(socket read/write, select, or so) is likely to
use this method. Though DRLVM using SIGUSR2 may not meet this problem(
does SIGUSR2 work on windows?). I agree this must be documented.


DRLVM doesn't use POSIX signals on windows if you mean if they work in DRLVM.

And if you mean whether they work in the same way as on Linux in regard of 
interrupting blocked IO I don't think so. POSIX signals on windows work in 
their own specific to windows kernel version way which makes them quite 
useless.




In this way I believe that method is necessary, maybe not only for 
windows but also for other platforms.



+1 of course to document to the above Geir question




--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-09 Thread Gregory Shimansky
On Friday 08 September 2006 06:03 Jimmy, Jing Lv wrote:
 Geir Magnusson Jr. wrote:
  This came up in another thread.
 
  Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on
  there being a setInterruptAction() method on java.lang.Thread.
 
  I certainly think that this kind of thing should be documented, so the
  question - should we add this to our Thread stub class?

 Yes, the VMs whose Thread do not know how to interrupt a certain
 understratum blocking I/O(socket read/write, select, or so) is likely to
 use this method. Though DRLVM using SIGUSR2 may not meet this problem(
 does SIGUSR2 work on windows?). I agree this must be documented.

DRLVM doesn't use POSIX signals on windows if you mean if they work in DRLVM.

And if you mean whether they work in the same way as on Linux in regard of 
interrupting blocked IO I don't think so. POSIX signals on windows work in 
their own specific to windows kernel version way which makes them quite 
useless.

+1 of course to document to the above Geir question

-- 
Gregory Shimansky, Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-07 Thread Geir Magnusson Jr.

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on 
there being a setInterruptAction() method on java.lang.Thread.


I certainly think that this kind of thing should be documented, so the 
question - should we add this to our Thread stub class?


geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-07 Thread Andrew Zhang

On 9/8/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:


This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on
there being a setInterruptAction() method on java.lang.Thread.

I certainly think that this kind of thing should be documented, so the
question - should we add this to our Thread stub class?



+1.
It is a part of vmi, and we should add setInterruptAction Thread stub
class as a private method. Thanks!


geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Andrew Zhang
China Software Development Lab, IBM


Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-07 Thread Jimmy, Jing Lv

Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on 
there being a setInterruptAction() method on java.lang.Thread.


I certainly think that this kind of thing should be documented, so the 
question - should we add this to our Thread stub class?




Yes, the VMs whose Thread do not know how to interrupt a certain 
understratum blocking I/O(socket read/write, select, or so) is likely to 
use this method. Though DRLVM using SIGUSR2 may not meet this problem( 
does SIGUSR2 work on windows?). I agree this must be documented.


But to DRLVM, one problem is how to tell the interruption is 
necessary(say, user invoke wake() or some other methods to ask them to 
stop) or can be ignored(say, caused by other unrelated interruption and 
can be recover like recently fix to hysock.c and socket.c).



geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?

2006-09-07 Thread Paulex Yang

Geir Magnusson Jr. wrote:

This came up in another thread.

Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends 
on there being a setInterruptAction() method on java.lang.Thread.


I certainly think that this kind of thing should be documented, so the 
question - should we add this to our Thread stub class?
I think so, actually it has been added as part of patch for HARMONY-635 
with documentations, but it was removed later for unknown reasons...I 
can recover it if no one objects.


geir

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]