Date: Sun, 26 Aug 2001 14:55:38 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Archie Cobbs <archie@dellroad.org>, arch@freebsd.org Subject: Re: changes to BSD APIs for THREADS support Message-ID: <3B89705A.A6EABECB@mindspring.com> References: <200108262010.f7QKA6f28508@arch20m.dellroad.org> <3B895DF7.709DB10C@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Archie Cobbs wrote: > > Julian Elischer writes: > > > 5/ It is possible that we may need a call by which the user thread > > > scheduler can 'cancel' the syscall that a particular kernel thread > > > is currently operating on. (particularly if it is waiting). > > > > I think this is going to be required. The UTS needs to have the > > ability to cancel a thread at any time. If the thread is in userland > > then it can just do it; otherwise it needs a way to wake up the > > thread in the kernel. The thread's syscall should then return > > immediately with EINTR or somesuch; alternately, the thread can > > just never return. Mabye both options would be good to have. > > the mechanics are the same as for the current code that aborts a > syscall when a signal is sent to the process, except that the > method of finding the sleeping party to unblock is slightly different. > > The syscall returns just like the current one would until it > reaches the kernel boundary. (it needs to unlock and free anything > it may have locked or allocated on the way in). At the boundary > we can just let it report a failure. The UTS can then cancel it. Julian, are you talking about EINTR handling (Archie's last sentence), or are you talking about his whole statement? If you are talking about his whole statement, I have to side with Archie: a blocking O_EXCL open on something like a modem would never be interruptable, without the ability to explicitly abort the system call as part of aborting/EINTR'ing the thread currently blocked on the call's completion. With POSIX signal handling, it's not like alarm(2) will do the right thing, as it would on a non-threaded program, and cause the call you want interrupted to properly return EINTR. I rather expect that you would have to establish a timer, take the signal on a particular thread (personally, I would suggest that whatever thread has registered a handler for a signal be chosen for delivery, over all other threads), and then re-throw the signal using pthread_kill or whatever. The EINTR would have to come from the interrupted call in the pthread_kill'ed thread. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B89705A.A6EABECB>