This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: threads and signals


Christopher Faylor wrote:
On Fri, May 09, 2003 at 05:18:05PM +0200, Thomas Pfaff wrote:

Christopher Faylor wrote:

On Fri, May 09, 2003 at 04:27:04PM +0200, Thomas Pfaff wrote:


As i already described in
http://cygwin.com/ml/cygwin-patches/2003-q2/msg00076.html the current
signal implementation does not work very well with multithreaded apps.

Before i start sending patches i would like to know if there is any
interest besides me for a change ?

As I'm sure you know -- this is a huge undertaking. That's why it is not implemented.

I think that it wouldn't make too much sense to start with it before the next cygwin release.
And it might make the current CVS unstable for a longer period, therefore i think it is better to create a separate CVS branch for these changes.

Before we do that, I'd like to hear what your plans are. I have some strong opinions about this so it won't make sense for you to start implementing things that I don't agree with.

One of my major concerns is that I don't want to impact performance.

I would start with :


1. Create a list of all pthreads. This can be done similar to the
already existing code for the other pthread objects.

2. Move sigthread mainthread and HANDLE signal_arrived into the thread
class. The pthread code creates a mainthread object too, so it would be
easy to make this move and keep the current code going (all signals will
be handled by the mainthread which should not be terminated). This will
make sure that only one thread will be interrupted and shouldn't impact
performance too much (Only a call to pthread_self must be issued to get
the signal_arrived handle).

3. Modify the signal code that signals issued by raise and pthread_kill
will be handled in the context of the signaled thread and will wake up
only that thread. Signals issued via kill will still be handled within
the mainthread. At the moment i am not sure how to deal with pending
signals on a per thread base but i think pending signals can be executed
when the threads signal mask is changed to unblock that signal.

4. Handle SIGSTOP and SIGCONT that these signals will suspend and resume
all threads.

5. Get rid of the mainthread object. This will be the hard work.
Add a signal bit mask into the thread class and represent a process wide
signal mask with counters. Every thread which does not block a signal
increments the counter. This makes it easy it create new threads
(increment according to the parent's signal mask), destroy a thread
(decrement according to the own mask), change (increment or decrement)
or test (counter greater than zero). If a signal can be delivered
immediately walk through the thread list to find the thread which can
get it. If it can't be delivered set it to pending and the first thread
the reenables it will get it.

6. Implement sigwait.

Thomas

P.S. : It might be that i am too blind to see but it seems that errno is
not thread specific. This will be the No. 1 topic to fix.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]