[haiku-development] Re: kill thread?
- From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 17 Aug 2012 19:40:03 -0700
On Fri, Aug 17, 2012 at 11:37:25PM +0200, Ingo Weinhold wrote:
> Pete Goodeve wrote:
> > On Thu, Aug 16, 2012 at 02:22:08PM +0200, Ingo Weinhold wrote:
> > > Pete Goodeve wrote:
> > > I believe sending other signals to threads is indeed not easily possible
> > > anymore. If it is any consolation, it never was in BeOS.
> > Actually BeOS lets you send any signal to a thread -- it just always
> > terminates it (:-/) [Maybe that's what you meant?]
>
> I stand corrected. Apparently BeOS used a kill command that indeed sends the
> signals to threads, not teams. Come to think of it, it actually makes sense,
> since BeOS doesn't support the concept of sending a signal to a team. It only
> supports sending signals to threads. That's part of why the BeOS signals
> implementation isn't POSIX compliant.
I really have to rethink my thinking about signals. I came up via Amiga
and BeOS (and never really needed them in the Unix stuff I was doing),
so I've always thought of them as being sent to tasks/threads for their
individual use. The ****x concept of a signal that has to be dealt with
by a handler is sufficiently different that I don't think I ever really grasped
it. (And BeOS never even provided for handlers as far as I know.)
>
> > Isn't the ability to send an 'out-of-band' notification to a thread
> > (waiting on a port or semaphore) somewhat important, though? I think
> > I've wanted to do that in the past [and probably never succeeded due
> > to the above... (:-/)]. How do you do that without signals?
>
> Not sure I follow. You can send a signal to a thread also in Haiku (via
> send_signal()), there just isn't any command line tool that does that ATM.
It's the receiving end that was concerning me (still probably in 'Amiga'
mode). I was thinking of a thread waiting on a message queue, that
needs to be told about something more urgent. But see below...
>
> [... useful clarifications skipped...].
>
> Haiku introduces the (experimental) wait_for_objects(), which allows you to
> wait for multiple events. I.e. the thread could not only wait for the
> semaphore, port, socket,... it wants to play with, but also for some other
> condition (e.g. a semaphore) for out-of-band notifications. I find this a
> much better approach than using signals.
Yes! This is the sort of feature I was wishing for. I'll have to go look.
>
> > After pawing through documents and experiments all day, the only
> > way I've found to have the thread skip a held semaphore is via
> > "suspend; resume", which is hardly intuitive! (And I see that the
> > BeBook says this is equivalent to 'SIGCONT', but it isn't either in Haiku
> > or BeOS! That signal seems to be the only one just ignored.)
>
> Either the documentation is incorrect or you misread something.
> On BeOS suspend_thread() is equivalent to sending a SIGSTOP and
> resume_thread() is equivalent to sending a SIGCONT.
Yeah, reading that section again ('in 'resume thread') I'd sort of merged
two sentences, The docs do actually describe things correctly.
-- Pete --
Other related posts:
