Re: [ECOS] Wake select() with a signal

[Roland Caßebohm <roland dot cassebohm at visionsystems dot de>]

On Dienstag, 5. November 2002 04:46, Jonathan Larmour wrote:
> Roland Caßebohm wrote:
>  > On Friday, 1. November 2002 18:04, Roland Caßebohm wrote:
>  >> Hi everyone,
>  >>
>  >> I want to wake a waiting select by sending a signal to the thread.
>  >>
>  >> This does not always work. I think the reason is that the thread in
>  >> which select() is call is not really sleeping all the time, even
>  >> though it doesn't return. The pthread_kill() function respectively
>  >> Cyg_Thread::release() only wakes a thread if the thread is sleeping.
>  >> That makes sense, but what can I do if I want a waiting select() to
>  >> return triggered from another thread?
>  >
>  > I just changed the select() function that it looks for the asr_pending
>  > flag before it goes to sleep. I don't really think, that this is the
>  > right solution, but in my case it works. Now the select() always
>  > returns with errno=EINTR if the thread receives a signal.
>
> Hmmm... Before the scheduler lock, the ASR should run. After the scheduler
> lock, nothing should be able to trigger an ASR to be scheduled; in
> particular nothing should be able to call pthread_kill. You're not calling
> pthread_kill from an ISR by any chance are you?

I call pthread_kill() from another thread.

>
> Oh, hold on, is it just that the pthread_kill is happening before the lock
> for the first time? If so, then I'm afraid that's tough - you could just
> as easily have pthread_kill'd it when the CPU was just making the call
> into the select function. From a programmatic point of view, that can just
> as easily happen. 

It could happen before the scheduler is locked for the first time, but 
allthough if an driver calls cyg_selwakeup() every select() function stops 
waiting and looks if one of the filedescriptors have a state which the user 
expected. If not, select() goes to sleep again.
In this time the scheduler is not locked, so pthread_kill() can be called.

> But your signal handler should definitely run
> regardless, or are you saying it doesn't do that either?

The signal handler doesn't run too. I think this is because by calling 
selwait.wait() asr_inhibit is set.

// Avoid calling ASRs during the following unlock.
    self->set_asr_inhibit();

>
>  > Does anybody know if the select() systemcall or every other systemcall
>  > should always return if the thread receives a signal?
>
> It should return if select() is actually waiting at the time.

Shouldn't it allthough return, if it is for any reason not waiting? I think 
the application just expects, that select() returns if a signal is received.

Roland

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss