Re: [Sablevm-developer] java.lang.Thread.yield()

[Chris P. <chr...@ma...>]

Prof. Etienne M. Gagnon wrote:

>On Wed, Feb 19, 2003 at 09:35:54PM -0500, Chris Pickett wrote:
>  
>
>>Okay.  Where is JNI_OK defined?
>>    
>>
>
>My first question would be: why do you need this information?
>  
>
Well it's used all over the place in your code and I thought it would 
help me to understand it better.  The reason I included it in that 
function was because there are many other uses of JNI_OK in 
java_lang_Thread.c.

Bruno just answered my question, so it's probably a good idea if I look 
at jni.h a bit.

>  
>
>>Well, actually, I realized last night about checking the error status, 
>>after I emailed you to say that I would send a patch today, but then 
>>today you had already committed the code.  Then I got caught up in 
>>making scripts, and didn't get around to telling you yet.
>>
>>sched_yield() returns 0 if there was no problem, or -1 if there was an 
>>error.
>>
>>sched_yield() is not necessarily posix compliant, so perhaps you'd 
>>better use pthread_yield() ... pthread_yield() doesn't return a value 
>>ever either, so just replace sched_yield() with pthread_yield() and 
>>forget about the error check.
>>    
>>
>
>
>My documentation says:
>
>$ man sched_yield
>...
>CONFORMING TO
>       POSIX.1b (formerly POSIX.4)
>...
>  
>
Okay, sched.h conforms to POSIX.1b, but it's still the GNU C library, so 
if you don't want dependence on sched.h then use pthread_yield().  They 
do the same thing . . .

>
>Also, aborting the VM if this call fails is quite dramatic!  The VM
>should only be aborted if you have detected an error in the VM itself,
>or if something REALLY bad happened (e.g. memory corruption).
>
Well, the sched_yield() documentation at

http://www.gnu.org/manual/glibc-2.2.5/html_node/Basic-Scheduling-Functions.html

says:

int *sched_yield*/ (void) / Function

This function voluntarily gives up the process' claim on the CPU.

Technically, |sched_yield| causes the calling process to be made 
immediately ready to run (as opposed to running, which is what it was 
before). This means that if it has absolute priority higher than 0, it 
gets pushed onto the tail of the queue of processes that share its 
absolute priority and are ready to run, and it will run again when its 
turn next arrives. If its absolute priority is 0, it is more 
complicated, but still has the effect of yielding the CPU to other 
processes.

If there are no other processes that share the calling process' absolute 
priority, this function doesn't have any effect.

To the extent that the containing program is oblivious to what other 
processes in the system are doing and how fast it executes, this 
function appears as a no-op.

The return value is |0| on success and in the pathological case that it 
fails, the return value is |-1| and |errno| is set accordingly. There is 
nothing specific that can go wrong with this function, so there are no 
specific |errno| values.


==============

And so I figured it was a pretty bad thing if the yield() didn't work 
because it says pathological, so I thought killing the VM was reasonable.

Again, I was just copying what you did elsewhere in the file.

>
>Otherwize, you throw either an "expected" exception (if appropriate),
>or you throw Error otherwise, as specified in the Java+JVM
>specifications.
>
>OK.  Next time you'll be more careful and ask questions if you are
>unsure. ;-)
>
>I encourage you to look at my fix to your code, once I check-it in
>CVS.
>
I will.  For now, you should probably check every line of code that I 
submit ... it's not so uncommon to have reviewers and even 
super-reviewers (for large projects).  However, everything's under 
revision control anyway so no matter what happens to the source tree it 
will never be the end of the world.

Cheers,
Chris