web: port-threads doc update

[Boehm, Hans]

I think it makes more sense to have it return void, since I think it can
only fail if we encounter a gcj bug, a CNI memory overwrite error, or the
like.  I think we want to keep tests out of that path unless they're really
necessary.

The pthreads version can currently return EINVAL if the mutex is bad, or
EDEADLK if we somehow managed to pass it an error checking mutex, which we
normally don't.  Both should be impossible.

AFAICT, the win32 version in my tree doesn't seem to deal with reentrant
mutexes correctly, it doesn't handle a WAIT_ABANDONED return value, and I
would guess it's quite slow.  And I don't have a good intuition for what it
should look like.  Thus it's probably not a good example for looking at
error handling issues.  (It's not clear to me what WAIT_ABANDONED should do.
It probably has to just block forever, though some sort of warning would be
nice ...)

Hans

> -----Original Message-----
> From: Tom Tromey [ mailto:tromey@redhat.com ]
> Sent: Saturday, December 15, 2001 3:55 PM
> To: Bryce McKinlay
> Cc: java-patches@gcc.gnu.org; hans_boehm@hp.com
> Subject: Re: web: port-threads doc update
> 
> 
> Bryce> 2001-12-15  Bryce McKinlay  <bryce@waitaki.otago.ac.nz>
> Bryce> 	* port-threads.html: Updated.
> 
> Thanks for doing this.  It was on my to-do list after seeing some of
> Adam's messages, but now it is off again.
> 
> Bryce>  <dt>int _Jv_MutexLock (_Jv_Mutex_t *mutex)
> 
> I notice we don't actually use the return result of this in libgcj.
> It seems like we should either use it, or we should redefine this to
> return `void' and simply throw an exception on error.  I've CCd Hans
> since I think he probably has an opinion on which would be better.
> 
> Tom
>