Evgueni Brevnov wrote:
In other words we will observe the crash as we do now if sem_wait
completes unsuccessfully for whatever reason...
Well it shouldn't return an error except for signal, shouldn't it? Two
possible other errors are EINVAL and EDEADLK which should never happen.
Maybe we should add an assertion after it that sem_wait was successful
to catch this situation quickly, and it will be a good starting point
for investigation.
On 11/17/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
Gregory,
The code which goes after sem_wait doesn't work properly if sem_wait
returns with an error code. So we need to either loop until sem_wait
returns successfully or adjust the code after sem_wait to handle
irregular cases.
Thanks
Evgueni
On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> Yes - that's why I was poking him to see the patch. I was going to
> suggest something very similar.
>
> geir
>
>
> Gregory Shimansky wrote:
> > Evgueni Brevnov wrote:
> >> You can look at the change here
> >> http://issues.apache.org/jira/browse/HARMONY-2203
> >
> > Could someone who knowns classlib native code internals better
than me
> > comment on this JIRA? I've added my comment from the general POV.
> >
> > I would change the loop to detect only signal interruption like
> >
> > while (sem_wait(&wakeUpASynchReporter) == -1 && errno == EINTR);
> >
> > Other than that I agree with the patch. I someone does not know,
every
> > step in gdb also interrupts sem_wait calls, so such loops are a
common
> > practice when using semaphores.
> >
> > If someone knows classlib internal logic with this asynchronous
handlers
> > stuff please write your opinion.
> >
>
--
Gregory
