[lkml]   [2000]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCO: "thread creation is about a thousand times faster than on native Linux"
> I don't understand this. If the user wants I/O to come in in order to 
> a particular thread, the user can make it predictable. POSIX allows the
> user to have more than one thread accepting signals -- sent to the
> process.

You need queue ordering on the signal

> But maybe you know the answer to this question: when a _thread_ initiates
> an async I/O, does it want a signal sent to the thread (pthread_kill) or
> to the process?

Its sent to whoever you set to be signalled on that fd.

The problem is the ordering of queued events versus close/open. You have to
have a single time ordered view in order to resolve the event list


open 5
close 5
open 5
data ready

indicating the data is ready for the first or second user of the fd. Unless you
have a single ordered view of events you have a problem. So we need to keep
stuff queued sensibly. Its the IRQ controller problem, and the two traditional
solutions are

- Given signal goes to a given task
- Further signals go to the task that has a signal pending.

> > The root thread cant catch SIGSTOP and reprocess it
> Why not? We let the root thread register itself with the kernel asking
> for raw signals. Now the root thread is not getting POSIX signals, but
> it is invisible to any POSIX processes.

SIGSTOP is unmaskable. Its a major and rather unwise change to do otherwise,
then there is SIGKILL which has similar issues.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.112 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site