Date: Sun, 26 Aug 2001 15:24:41 -0700 From: Julian Elischer <julian@elischer.org> To: tlambert2@mindspring.com Cc: Archie Cobbs <archie@dellroad.org>, arch@freebsd.org Subject: Re: changes to BSD APIs for THREADS support Message-ID: <3B897729.FF577A21@elischer.org> References: <200108262010.f7QKA6f28508@arch20m.dellroad.org> <3B895DF7.709DB10C@elischer.org> <3B89705A.A6EABECB@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
>
> 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.
I think you are getting a little carried away here..
Basically any sleeping kernel thread must be cancelable.
When it is cancelled it must free any resources it has.
To do this it needs to rewind through it's stack to the user boundary.
When it reaches there, we can do what ever we want with it..
My suggestion is that we report a 'cancelled' state back to the UTS,
and let it decide what to do (restart it,
erase the whole userland thread, whatever). This is the same
mechanism as used by the current code to abort a syscall when a
signal is caught (kill -9 should abort most syscalls).
the actual code returned is probably neither EINTR or ERESTART
or anything, but probably a code specific to the KSE environment.
Signals are a whole different topic. They are delivered on the next
upcall to any KSE within the process. The UTS is notified of the
signals , and can do what it likes with them, including ignoring them,
or passing them o a particular thread, or even starting a separate thread
to handle them. That is the UTS's perogative.
>
> 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.
you are being too specific here. That's all the UTS's decision.
>
> -- Terry
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
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?3B897729.FF577A21>