RE: [PATCH] minor pthread fixes

Thank you. BTW i realized that Chris hasn't got an assignment from me yet. I will send one in the next days. Regards, Thomas On Wed, 5 Jun 2002, Robert Collins wrote: > Thanks, applied. > > > -Original Message- > > From: Thomas Pfaff [mailto:[EMAIL PROTECTED]]

RE: [PATCH] added locks in pthread code

unctions (from the standard) are not > cancellable. > > Rob > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Robert Collins > > Sent: Monday, 10 June 2002 12:24 PM > > To: 'Thomas Pfaf

Re: Pthreads patches

Hi Rob, i had a minor problem with your latest code: You decided to change the mutex pointer into an object. This will break the verifyable_object_isvalid call in pthread::create. I have attached a small patch, a cancellation patch will follow. Thomas 2002-06-12 Thomas Pfaff <[EM

RE: Pthreads patches

On Wed, 12 Jun 2002, Robert Collins wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On Behalf Of Thomas Pfaff > > Sent: Wednesday, 12 June 2002 9:17 PM > > To: [EMAIL PROTECTED] > > Subject: R

Re: Pthreads patches

I am sorry, but i recognized that my patch was incomplete. The diff included only threads.cc. I have attached a new one. Thomas 2002-06-12 Thomas Pfaff <[EMAIL PROTECTED]> * thread.h (pthread::cleanup_stack): Renamed cleanup_handlers to cleanup_stack. * thr

[PATCH] pthread cancellation

This patch provides a pthread cancellation implementation. Rob, please mail me if you can't read the attachment. Thomas 2002-06-25 Thomas Pfaff <[EMAIL PROTECTED]> * include/pthread.h (PTHREAD_CANCELED): Defined a reasonable value. * pthread.cc (pthread_

Additional trace printf in pthread::create

Changelog 2002-06-27 Thomas Pfaff <[EMAIL PROTECTED]> *thread.cc (pthread::create): Added trace printf to get CreateThread LastError. diff -urp src.old/winsup/cygwin/thread.cc src/winsup/cygwin/thread.cc --- src.old/winsup/cygwin/thread.cc Mon Jun 24 03:12:3

Re: [PATCH] pthread_fork Part 1

On Mon, 16 Sep 2002, Robert Collins wrote: > On Sat, 2002-08-17 at 06:18, Thomas Pfaff wrote: > > > > Rob suggested to break the pthread_fork patch into smaller chunks. Ths is > > part 1 providing a fork save key value handling. > > The patch will add a linked list

[PATCH] new mutex implementation 2. posting

you will not get an EDEADLOCK on locking twice, it WILL deadlock instead). With my previous 2 patches and this one i was able to build and run a threaded perl that has passed all tests (to be true it failed 3 but these were really not pthread related). 2002-08-15 Thomas Pfaff <[EMAIL PROTEC

Re: [PATCH] pthread_fork Part 2

On Tue, 17 Sep 2002, Robert Collins wrote: > On Sat, 2002-08-17 at 06:32, Thomas Pfaff wrote: > > > > Some small fixes in the pthread key handling. > > @@ -1020,16 +1020,27 @@ pthread_key::~pthread_key () > > int > > pthread_key::set (const void *value

Re: [PATCH] new mutex implementation 2. posting

On Tue, 17 Sep 2002, Robert Collins wrote: > On Tue, 2002-09-17 at 19:34, Thomas Pfaff wrote: > > > > This patch contains a new mutex implementation. > > > > The advantages are: > > > > - Same code on Win9x and NT. Actual are critical sections used on NT

Re: [PATCH] new mutex implementation 2. posting

On Fri, 20 Sep 2002, Robert Collins wrote: > On Tue, 2002-09-17 at 19:34, Thomas Pfaff wrote: > > Thomas, the patch is incomplete. > > pthread_cond::TimedWait needs updating as well... Yup, but it seems that this was broken on NT before i made my changes, because it was never

Re: [PATCH] pthread_fork Part 3

On Fri, 20 Sep 2002, Robert Collins wrote: > On Sat, 2002-08-17 at 06:55, Thomas Pfaff wrote: > > > > Pthread key destructor handling revised. IMHO it does not make sense to > > handle two lists with keys, one with all keys, one with its destructors. > > The destruct

Re: [PATCH] new mutex implementation 2. posting

On Sun, 22 Sep 2002, Robert Collins wrote: > On Sat, 2002-09-21 at 01:47, Christopher Faylor wrote: > > I haven't been following very closely. Is the reason why we are not using > > critical sections that TryEnterCriticalSection isn't available anywhere? > > If so, then we can probably fix tha

[PATCH] updated mutex implementation

This patch contains an update of my mutex implementation that should apply to current. 2002-09-23 Thomas Pfaff <[EMAIL PROTECTED]> * include/pthread.h: Change default mutex type to errorcheck. * thread.cc (pthread_cond::TimedWait): Fix mutex unlock call. (pthread

[PATCH] pthread key destructor

See http://www.opengroup.org/onlinepubs/007904975/functions/pthread_key_create.html I do not think that we should support more than one iterations at the moment. This seems to be a rather new addition to the pthread specification. 2002-09-23 Thomas Pfaff <[EMAIL PROTEC

[PATCH] Reset threadcount after fork

2002-09-23 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (MTinterface::fixup_after_fork): Reset threadcount to 1 after fork. diff -urp src.old/winsup/cygwin/thread.cc src/winsup/cygwin/thread.cc --- src.old/winsup/cygwin/thread.cc Mon Sep 23 14:26:30 2002 +++ src/

Re: [PATCH] new mutex implementation 2. posting

On Sun, 22 Sep 2002, Robert Collins wrote: > On Sat, 2002-09-21 at 01:47, Christopher Faylor wrote: > > I haven't been following very closely. Is the reason why we are not using > > critical sections that TryEnterCriticalSection isn't available anywhere? > > If so, then we can probably fix tha

Re: [PATCH] Reset threadcount after fork

On Mon, 23 Sep 2002, Robert Collins wrote: > On Mon, 2002-09-23 at 22:36, Thomas Pfaff wrote: > > > > 2002-09-23 Thomas Pfaff <[EMAIL PROTECTED]> > > > > * thread.cc (MTinterface::fixup_after_fork): Reset threadcount to > > 1 after fork. > &

[PATCH] MTinterface patch part 1

This is part 1 of 3 patches for the MTinterface. It provides a more general implementation of Robs initMainThread that could be used also to assign thread handles for threads that are created outside pthread (via CreateThread). 2002-09-24 Thomas Pfaff <[EMAIL PROTECTED]> * thr

[PATCH] MTinterface patch part 2

This is patch 2 of 3 for MTinterface. It will convert the TLS handling for reents and thread self pointer to use the fork save pthread keys. This is important for forks from threads other than the main thread. 2002-09-24 Thomas Pfaff <[EMAIL PROTECTED]> * init.cc (dll_entry):

[PATCH] MTinterface patch part 3

This is patch 3 of 3. It will change thread cleanup to use a destructor function. 2002-09-24 Thomas Pfaff <[EMAIL PROTECTED]> * init.cc (dll_entry): Run pthread key destructors on thread detach. * thread.cc (pthread::destructor): Implement. (pthread

[PATCH] MTinterface patch part 4

Check for valid pthread object to avoid deletion of Nullpthread. 2002-09-25 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (pthread::destructor): Check for valid pthread object prior to delete. diff -urp src.old/winsup/cygwin/thread.cc src/winsup/cygwin/thread.cc --- s

[PATCH] fix segv in pthread_mutex::init

This patch should fix the segfault in pthread_mutex::init by changing the test order for a valid object and checking for valid initializer object first.. Thomas 2002-10-17 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (verifyable_object_isvalid): Test for static object

Re: [PATCH] fix segv in pthread_mutex::init

Stripped the patch a little. Changelog remains unchanged. Thomas 2002-10-17 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (verifyable_object_isvalid): Test for static object first. (pthread_mutex::init): Add test for valid initializer object. On Thu, 17 Oc

Re: [PATCH] fix segv in pthread_mutex::init

On Thu, 17 Oct 2002, Robert Collins wrote: > On Thu, 2002-10-17 at 18:11, Thomas Pfaff wrote: > > > > This patch should fix the segfault in pthread_mutex::init by changing the > > test order for a valid object and checking for valid initializer object > > fir

[PATCH] verifyable_object_isvalid

Rob, the location for the static test is wrong. I have moved it 2 lines down. Thomas 2002-10-18 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (verifyable_object_isvalid): Test for a valid object pointer before testing for static ptr. --- thread.cc.org Thu Oct 17

[PATCH] fhandler_socket::recvmsg [WAS: Anyone interested in checkingout dgram socket problem (Conrad you still here?)]

f > > http://cygwin.com/ml/cygwin/2002-10/msg01974.html > It seems that the fromlen in WSARecvFrom must be NULL if from is NULL and not a pointer to 0. Actually msg->msg_name is NULL and msg->msg_namelen is 0 which will result in WSAEFAULT. Thomas 2002-11-05 Thomas Pfa

[PATCH] Patch for MTinterface

read_exit). And the newly created object never gets freed. To avoid these errors i have made changes that will create the mainthread object dynamic and store the reents and thread self pointer via fork safe keys. Thomas 2002-11-05 Thomas Pfaff <[EMAIL PROTECTED]> * dcrt

Re: [PATCH] Patch for MTinterface

On Tue, 5 Nov 2002, Robert Collins wrote: > On Wed, 2002-11-06 at 00:14, Thomas Pfaff wrote: > > > > I have discovered some problems with the current MTinterface > > implementation. Here are 2 test cases: > > > Even if the handles would be valid the pthread_join

Re: [PATCH] Patch for MTinterface

On Tue, 5 Nov 2002, Robert Collins wrote: > Overall this looks good. What happens to non-cygwinapi created threads > now though? You mention you don't agree with the code, but I can't see > (from a brief look) how you correct it. > > BTW: I'm currently packing to move house, so don't expect much

[PATCH] Remove libstdc++ from cygwin1.dll build

the nothrow new operators, i think that the cleanest way is to define own operators. As a side effect the cygwin1 dll can be build with an sjlj gcc and the dll is significantly smaller. Thomas 2002-11-26 Thomas Pfaff <[EMAIL PROTECTED]> * cxx.cc: New file. Implement new, new[],

Re: [PATCH] Remove libstdc++ from cygwin1.dll build

mailing list called "DLLs and Exceptions" discussing the pros and cons of sjlj and dwarf2. Whatever exception type is preferred by the cygwin gcc package i do not think that the cygwin1.dll should ever throw an exception. 2002-11-26 Thomas Pfaff <[EMAIL PROTECTED]> *

[PATCH] pthread_cond_init

Rob has added a native mutex around mutex initialization to avoid a race. This is required in pthread_cond_init too. I have moved the nativeMutex class outside of pthread_mutex and added similar calls to pthread_cond to avoid that race. Thomas 2002-11-29 Thomas Pfaff <[EMAIL PROTEC

[PATCH] pthread_mutex patches

This is my patch from 2002-09-17 ported to the recent cygwin src. (See http://cygwin.com/ml/cygwin-patches/2002-q3/msg00436.html). pthread_cond_init patch should be applied first. 2002-12-04 Thomas Pfaff <[EMAIL PROTECTED]> * include/pthread.h: Add define for errorchecking m

Re: [PATCH] pthread_mutex patches

Changed spaces to tabs in Changelog. Sorry. 2002-12-04 Thomas Pfaff <[EMAIL PROTECTED]> * include/pthread.h: Add define for errorchecking mutexes. Change default mutex type. * thread.cc (pthread_cond::TimedWait): Update mutex unlock calls. (pthread

Re: [PATCH] pthread_cond_init

The patch has been made a little smaller and better readable by not changing the functions order in thread.cc 2002-12-10 Thomas Pfaff <[EMAIL PROTECTED]> * pthread.cc (pthread_cond_init): Use new pthread_cond::init. * thread.cc: Some white spaces cleanups.

Re: [PATCH] pthread_mutex patches

-win32 maintainer. 2002-12-11 Thomas Pfaff <[EMAIL PROTECTED]> * include/pthread.h: Add define for errorchecking mutexes. Change default mutex type. * thread.cc (pthread_cond::TimedWait): Update mutex unlock calls. (pthread_mutex::pthread_mutex

Re: quandary with pthreads

I have attached a bunch of mutex testcases borrowed from the pthreads-win32 project. Thomas On Wed, 11 Dec 2002, Thomas Pfaff wrote: > > > Rob, > > thank you that you are willing to add my patches. > > FYI, the logic of the mutex stuff is running in pthreads-win32 ab

[PATCH] cancellation revised

While Chris is waiting on Rob (or vice versa) i got a new pthread related patch which will make pthread_join and sem_wait real cancellation points. TODO: Add testcancel to other cancelation points. Thomas 2002-12-20 Thomas Pfaff <[EMAIL PROTECTED]> * thread.h (WAIT_CANCELED

[PATCH] Make sleep and usleep a cancellation point

This patch will make sleep and usleep a pthread cancellation point. 2003-01-10 Thomas Pfaff <[EMAIL PROTECTED]> * signal.cc (sleep): Add pthread_testcancel call. Wait for signal and cancellation event. (usleep): Ditto. diff -urp src.old/winsup/cygwin/signal.

[PATCH] make handle_sigsuspend a cancellation point

This patch will make handle_sigsuspend (used by pause, sigpause and sigsuspend) a pthread cancellation point. 2003-01-10 Thomas Pfaff <[EMAIL PROTECTED]> * exceptions.cc (handle_sigsuspend): Add pthread_testcancel call. Wait for signal and cancellation

test cases for cancellation patches

Attached are test cases for the cancellation patches. Thomas pthreads-test.tar.gz Description: GNU Zip compressed data

[PATCH] Make wait4 a pthread cancellation point

Attached is a patch and a test case for wait4 (used by wait, wait3 and waitpid). 2003-01-13 Thomas Pfaff <[EMAIL PROTECTED]> * wait.cc: Include thread.h (wait4): Add pthread_testcancel call. Wait for child process and cancellation event. * thread.cc: Updat

[PATCH] Make system a pthread cancellation point

Sorry, no testcase for that patch (it is really to simple). I will commit my outstanding patches today. Thomas 2003-01-14 Thomas Pfaff <[EMAIL PROTECTED]> * syscalls.cc (system): Add pthread_testcancel call. * thread.cc: Update list of cancellation points. dif

Re: [PATCH] Make system a pthread cancellation point

On Tue, 14 Jan 2003, Robert Collins wrote: > On Tue, 2003-01-14 at 21:50, Thomas Pfaff wrote: > > Sorry, no testcase for that patch (it is really to simple). > > I think it really is worth adding test cases - even for simple things. > > It prevents regressions, which i

[PATCH] system-cancel part2

This patch will make sure that the signal handlers that are saved in the system call are restored even if the thread got cancelled. Since spawn_guts uses waitpid when mode is _P_WAIT spawn_guts is a cancellation point. Attached is the patch and a new test case. 2003-01-15 Thomas Paff <[EMAIL P

Re: [PATCH] system-cancel part2

On Wed, 15 Jan 2003, Robert Collins wrote: > On Wed, 2003-01-15 at 22:23, Thomas Pfaff wrote: > > This patch will make sure that the signal handlers that are saved in the > > system call are restored even if the thread got cancelled. Since > > spawn_guts uses waitpid

[PATCH] a new pthread_cond implementation

ds_win32. As a side effect thread.cc will shrink significantly. 2003-01-23 Thomas Pfaff <[EMAIL PROTECTED]> * thread.h (pthread_mutex::canBeUnlocked): New static method. (pthread_cond::ExitingWait): Remove. (pthread_cond::mutex): Ditto. (pthread

Re: [PATCH] a new pthread_cond implementation

On Thu, 23 Jan 2003, Robert Collins wrote: > On Thu, 2003-01-23 at 23:21, Thomas Pfaff wrote: > > > > 4. The spec requires that the mutex which is used with the condition > > shall be locked by the calling thread. The current code does not check > > this and will ad

[PATCH] MTInterface fixup_after_fork

Required for the rwlock patch. 2003-02-27 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (MTinterface::fixup_after_fork): Initialize mainthread prior to pthread objects. diff -urp src.old/winsup/cygwin/thread.cc src/winsup/cygwin/thread.cc --- src.old/winsup/cygwin/thr

[PATCH] add support for PTHREAD_MUTEX_NORMAL

This patch adds support for PTHREAD_MUTEX_NORMAL (fast and deadlocking) mutexes and slightly modifies the lock counter logic. The counter now start at 0. Attached are also additional testcases for the MUTEX_NORMAL type. 2002-03-27 Thomas Pfaff <[EMAIL PROTECTED]> * include/pth

[PATCH]: Updated pthread_cond patch.

This is a slightly modified version of my still pending patch. The modifications were made to support rwlocks. 2003-02-27 Thomas Pfaff <[EMAIL PROTECTED]> * thread.h (pthread_cond::ExitingWait): Remove. (pthread_cond::mutex): Ditto. (pthread_cond::cond_access):

[PATCH] Implement pthread_rwlocks

This patch adds support for pthread_rwlocks. Attached are testcases from the pthreads-win32 project. The rwlock implementation follows the opengroup spec that it will prefer writers among readers and check for deadlock conditions. 2003-02-27 Thomas Pfaff <[EMAIL PROTEC

[PATCH]: interruptable connect

Hi Corinna, this is a slightly modified version of my proposed solution from yesterday. Not tested exhaustiv but seems to work pretty well. Thomas 2003-03-27 Thomas Pfaff <[EMAIL PROTECTED]> * fhandler_socket.cc (fhandler_socket::connect): Add support for an interru

[PATCH] reorganize list handling of fixable pthread objects

Reorganize the list handling of the pthreads objects by using the List template class and remove a lot of duplicate code. 2002-02-28 Thomas Pfaff <[EMAIL PROTECTED]> * thread.h (class List): Move inline code inside of class declaration. (pthread

[PATCH] Remove wrapper functions in pthread.cc

This patch removes all wrapper functions in pthread.cc that only add an additional function call. Export the functions in thread.cc instead. 2003-02-28 Thomas Pfaff <[EMAIL PROTECTED]> * pthread.cc (pthread_attr_init): Remove (pthread_attr_destroy):

Re: [PATCH] Remove wrapper functions in pthread.cc

On Fri, 28 Feb 2003, Robert Collins wrote: > On Sat, 2003-03-01 at 00:53, Thomas Pfaff wrote: > > This patch removes all wrapper functions in pthread.cc that only add an > > additional function call. Export the functions in thread.cc instead. > > Please apply. > I

Re: [PATCH] add support for PTHREAD_MUTEX_NORMAL

On Thu, 27 Feb 2003, Robert Collins wrote: > On Thu, 2003-02-27 at 23:26, Thomas Pfaff wrote: > > This patch adds support for PTHREAD_MUTEX_NORMAL (fast and > > deadlocking) mutexes and slightly modifies the lock counter logic. > > The counter now start at 0. > &g

Re: [PATCH] add support for PTHREAD_MUTEX_NORMAL

On Thu, 13 Mar 2003, Cygwin (Robert Collins) wrote: > This: > >if (1 == InterlockedIncrement ((long *)&lock_counter)) > > is not safe. You can only check for equal to 0, less than 0, and greater > than 0 with InterlockedIncrement | Decrement. > The xadd based inline interlocked functions in

Re: [PATCH] add support for PTHREAD_MUTEX_NORMAL

On Wed, 19 Mar 2003, Robert Collins wrote: > On Mon, 2003-03-17 at 19:17, Thomas Pfaff wrote: > > On Thu, 13 Mar 2003, Cygwin (Robert Collins) wrote: > > > > > This: > > > > > >if (1 == InterlockedIncrement ((long *)&lock_counter)) > > &g

Re: [PATCH] reorganize list handling of fixable pthread objects

> template > T& for_each(L const &start,, L const& finish, T& visitor) > { > for (L current (start); current != finish; ++current) > visitor(*current); > return visitor; > } > > > On Fri, 2003-02-28 at 22:10, Thomas Pfaff wrote: &

Re: [PATCH] add support for PTHREAD_MUTEX_NORMAL

On Wed, 19 Mar 2003, Robert Collins wrote: > On Wed, 2003-03-19 at 21:15, Thomas Pfaff wrote: > > > > > > Secondly, IIRC lock_counter should be long, so the (long *) typecasting > > > > > isn't needed. > > > > > > > > IM

[PATCH] Add unsigned long Interlocked functions

2003-03-19 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (pthread_cond::Wait): Remove typecasts for unsigned long values when calling Interlocked functions. Use new UL functions instead. (pthread_mutex::_Lock): Ditto. (pthread_mutex::_TryLock):

[PATCH] pthread_equal

2003-03-19 Thomas Pfaff <[EMAIL PROTECTED]> * pthread.cc (pthread_equal): Replacement for pthread_equal in thread.cc. * thread.cc: Rename pthread_equal to pthread::equal throughout. (pthread_equal): Remove. * thread.h (pthread::equal): New static

[PATCH] updated pthread list patch

2002-03-19 Thomas Pfaff <[EMAIL PROTECTED]> * thread.h (class List): Move inline code inside class declaration. (List::forEach): Change callback parameter to member function pointer. (pthread_keys::fixup_before_fork): Change to inline. Use

Re: [PATCH] pthread_equal

On Wed, 19 Mar 2003, Robert Collins wrote: > On Thu, 2003-03-20 at 00:54, Thomas Pfaff wrote: > > 2003-03-19 Thomas Pfaff <[EMAIL PROTECTED]> > > > > * pthread.cc (pthread_equal): Replacement for pthread_equal in > > thread.cc. > > * thr

Re: [PATCH] updated pthread list patch

On Wed, 19 Mar 2003, Robert Collins wrote: > I'm happy with changing the method naming format, but is it GNU > standard? Thats a requirement for the cygwin project. > > http://www.gnu.org/prep/standards_26.html#SEC26 says that > "For example, you should use names like ignore_space_change_flag; d

Re: [ford@vss.fsi.com: [PATCH] Trivial pthread testsuite fixes]

Christopher Faylor wrote: I assume that these patches are to clean up some warnings. Do they make sense? Yes. I have recognized these warnings yesterday too and will apply the patch. Thomas

[PATCH] Change pthread equations

2003-03-27 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc: Change 1==foo equations to foo==1 throughout. diff -urp src.old/winsup/cygwin/thread.cc src/winsup/cygwin/thread.cc --- src.old/winsup/cygwin/thread.cc 2003-03-27 12:56:03.0 +0100 +++ src/winsup/cygwin/thread.c

[PATCH] Return correct error code on subsequent nonblocking connect

EINPROGRESS. Attached patch fix this to return EALREADY on the second and all following connects. As a side effect this will change interrupted blocking connects to return EALREADY too (and not block again) as we have discussed before. I think that this more opengroup alike. Thomas 2003-06-06 Thomas

Re: [RFA] enable dynamic (thread safe) reents

Christopher Faylor wrote: On Fri, May 16, 2003 at 02:12:16PM +0200, Thomas Pfaff wrote: Thomas Pfaff wrote: While single threaded apps should keep run without problems (_impure_ptr is still used for the mainthread) multithreaded apps should be recompiled to get the full power of the thread safe

Re: [RFA] enable dynamic (thread safe) reents

Christopher Faylor wrote: On Fri, Jun 13, 2003 at 08:20:47AM +0200, Thomas Pfaff wrote: Unfortunately stdin, stdout and stderr were defined with _REENT directly. Sigh. I've checked in this patch. I'll ask again if it makes sense to fix this problem in newlib. Does it? It is a littl

Re: [PATCH] pthread patch - Thomas Pfaff, please note

Christopher Faylor wrote: Thomas, I made the change below to stop a SEGV on thread exit as evinced by the threadidafterfork test in the testsuite. The problem is that this code overwrites impure_ptr with the contents of the thread which called fork, which is not the correct thing to do since _impur

[PATCH] suspend all thread on SIGSTOP

This patch suspends all threads on SIGSTOP and resumes them on SIGCONT. The corresponding functions in the pthread class are already committed. Thomas 2003-10-31 Thomas Pfaff <[EMAIL PROTECTED]> * exceptions.cc (sig_handle_tty_stop): Suspend all threads on SIGSTOP,

[PATCH] Fix debugger attach for threads

debbugging loop is implemented this way. Thomas 003-10-31 Thomas Pfaff <[EMAIL PROTECTED]> * exceptions.cc (try_to_debug): Suspend/resume all threads when a debugger is attaching. (handle_exceptions): Give debugger CPU time to attach. ? suspend_all_on_stop

[PATCH] suspend all thread on SIGSTOP

This time with attachment. This patch suspends all threads on SIGSTOP and resumes them on SIGCONT. The corresponding functions in the pthread class are already committed. Thomas 2003-10-31 Thomas Pfaff <[EMAIL PROTECTED]> * exceptions.cc (sig_handle_tty_stop): Suspe

Re: [PATCH] suspend all thread on SIGSTOP

Christopher Faylor wrote: On Fri, Oct 31, 2003 at 10:17:37PM +0100, Thomas Pfaff wrote: This time with attachment. This patch suspends all threads on SIGSTOP and resumes them on SIGCONT. The corresponding functions in the pthread class are already committed. Thomas 2003-10-31 Thomas Pfaff

Re: [PATCH] Fix debugger attach for threads

Christopher Faylor wrote: On Fri, Oct 31, 2003 at 10:11:46PM +0100, Thomas Pfaff wrote: This patch allows a debugger to attach when an exception occurs in a thread other than the mainthread. I am not happy about the wait in handle_exceptions, but it works on my machine. I think that a waitloop

Re: [PATCH] Fix debugger attach for threads

Christopher Faylor wrote: On Fri, Oct 31, 2003 at 10:11:46PM +0100, Thomas Pfaff wrote: This patch allows a debugger to attach when an exception occurs in a thread other than the mainthread. I am not happy about the wait in handle_exceptions, but it works on my machine. I think that a waitloop

[PATCH] stdio initialization

Attached patch fixes the memory leak reported by Arash Partow by initializing stdio during startup and setting __sdidinit from thread local clib appropriately. Thomas 2003-11-10 Thomas Pfaff <[EMAIL PROTECTED]> * dcrt0.cc: Add prototype for __sinit. (dll_crt0_1): Init

Re: [PATCH] stdio initialization

Christopher Faylor wrote: On Mon, Nov 10, 2003 at 12:23:35PM +0100, Thomas Pfaff wrote: Attached patch fixes the memory leak reported by Arash Partow by initializing stdio during startup and setting __sdidinit from thread local clib appropriately. Thomas 2003-11-10 Thomas Pfaff <[EM

Re: [PATCH] stdio initialization

Christopher Faylor wrote: On Mon, Nov 10, 2003 at 03:03:06PM +0100, Thomas Pfaff wrote: Christopher Faylor wrote: On Mon, Nov 10, 2003 at 12:23:35PM +0100, Thomas Pfaff wrote: Attached patch fixes the memory leak reported by Arash Partow by initializing stdio during startup and setting

Re: [PATCH] stdio initialization

Christopher Faylor wrote: On Mon, Nov 10, 2003 at 10:09:52AM -0500, Christopher Faylor wrote: On Mon, Nov 10, 2003 at 03:03:06PM +0100, Thomas Pfaff wrote: Christopher Faylor wrote: On Mon, Nov 10, 2003 at 12:23:35PM +0100, Thomas Pfaff wrote: Attached patch fixes the memory leak reported by

Re: [PATCH] stdio initialization

Christopher Faylor wrote: Actually, on poking around a little, I wonder if we should be calling _reclaim_reent to get back all of the stuff allocated in the REENT structure? I think you are right. Here is my patch to thread.cc that i will apply if there are no objections. diff -urp src.org/thread.c

[PATCH]: Error checking in init_main_thread

Chris, while the cancel event creation looks good now i would make sure that the process is created only when the handles are valid. Thomas 2003-15-15 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (pthread::init_main_thread): Make sure that the main thread has valid h

Re: [PATCH]: Error checking in init_main_thread

On Mon, 15 Dec 2003, Thomas Pfaff wrote: > Chris, > > while the cancel event creation looks good now i would make sure that > the process is created only when the handles are valid. > > Thomas > > 2003-15-15 Thomas Pfaff <[EMAIL PROTECTED]> 2003-12-15

[PATCH]: Thread safe stdio

my patch for newlib will be accepted. Regards, Thomas 2004-01-12 Thomas Pfaff <[EMAIL PROTECTED]> * include/sys/_types.h: New file. * include/sys/lock.h: Ditto. * include/sys/stdio.h: Ditto. * thread.cc: Include sys/lock.h (__cygwin_lock_init_rec

Re: [PATCH]: Thread safe stdio

Please ignore this patch, i will generate a new one soon. Thomas Thomas Pfaff wrote: This patch adds support for thread safe stdio. It will add 3 new header files three which supersedes newlib ones. One of these (_types.h) is just a copy of newlibs _types.h with a modified _lock_t. It is not

[PATCH]: Thread safe stdio update

) == sizeof(void*). 2004-01-19 Thomas Pfaff <[EMAIL PROTECTED]> * include/sys/_types.h: New file. * include/sys/lock.h: Ditto. * include/sys/stdio.h: Ditto. * thread.cc: Include sys/lock.h (__cygwin_lock_init_recursive): New fu

[PATCH]: 2. Thread safe stdio update

This is an update of my previous patch. It adds support for newlibs __LOCK_INIT macro. Thomas 2004-01-22 Thomas Pfaff <[EMAIL PROTECTED]> * include/sys/_types.h: New file. * include/sys/lock.h: Ditto. * include/sys/stdio.h: Ditto. * thread.cc: Include sys/

Re: [PATCH]: 2. Thread safe stdio update

Corinna Vinschen wrote: On Jan 22 21:48, Thomas Pfaff wrote: This is an update of my previous patch. It adds support for newlibs __LOCK_INIT macro. Thomas 2004-01-22 Thomas Pfaff <[EMAIL PROTECTED]> * include/sys/_types.h: New file. I'm not quite sure if that's the

[PATCH] Thread safe stdio

; The __sinit call must be done after malloc is initialized, otherwise the mutex creation will fail. Thomas 2004-02-11 Thomas Pfaff <[EMAIL PROTECTED]> * include/cygwin/_types.h: New file. * include/sys/lock.h: Ditto. * include/sys/stdio.h: Ditto. * dc

Re: Re: [PATCH] Thread safe stdio

earlier does no harm, AFAICS. The > rest of the Cygwin patch should obviously wait. > Igor > Igor, include/cygwin/_types.h is part of the patch, see Changelog: 2004-02-11 Thomas Pfaff <[EMAIL PROTECTED]> * include/cygwin/_types.h: New file. The patch for newlibs _

Re: [PATCH] Thread safe stdio

Christopher Faylor wrote: On Wed, Feb 11, 2004 at 11:08:57AM +0100, Thomas Pfaff wrote: The __sinit call must be done after malloc is initialized, otherwise the mutex creation will fail. I am not comfortable with this part of the patch. I moved the __sinit call where I did for a reason. It

[PATCH] Add support for non portable mutex initializers

initializers can be used for example to enable thread safe stdio in newlib without moving __sinit. I really want to get this fixed. Thomas P.S.: I will be on winter vacation next week, no reply during that time. 2004-02-20 Thomas Pfaff <[EMAIL PROTECTED]> * winsup.api/pthread/mutex8e.

Re: [PATCH] Add support for non portable mutex initializers

Christopher Faylor wrote: This looks like it simplifies mutex handling a lot. I haven't investigated in great detail but since you've provided some test cases, feel free to check in. I tried but it seems that my ssh login is no longer valid, i get: cvs -z9 -d :ext:[EMAIL PROTECTED]:/cvs/src co src

[RFA]: Thread safe stdio again

This time i am using the non portable mutex initializers, therefore moving __sinit is no longer needed. And i added calls to newlibs __fp_lock_all and __fp_unlock_all at fork. 2004-03-14 Thomas Pfaff <[EMAIL PROTECTED]> * include/cygwin/_types.h: New file. * include/sys/

Re: [RFA]: Thread safe stdio again

Christopher Faylor wrote: On Fri, Mar 26, 2004 at 01:50:08AM -0500, Christopher Faylor wrote: On Sun, Mar 14, 2004 at 08:28:02PM +0100, Thomas Pfaff wrote: This time i am using the non portable mutex initializers, therefore moving __sinit is no longer needed. And i added calls to newlibs

[PATCH]: Trivial move in pthread::atforkprepare

MT_INTERFACE->fixup_before_fork () should be done as the last step in pthread::atforkprepare. I am sorrry if the Changelog contains spaces, but i have limited internet access at the moment (only Webmail). 2004-03-29 Thomas Pfaff <[EMAIL PROTECTED]> * thread.cc (pthread::atfo

  1   2   >