From f0c403f525de427b961c24fff6eef88967e4b29f Mon Sep 17 00:00:00 2001 From: Julian Seward Date: Wed, 29 May 2002 20:23:26 +0000 Subject: [PATCH] Update TODO lists at the top of the file. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@336 --- coregrind/vg_scheduler.c | 18 ++++++++++++++---- vg_scheduler.c | 18 ++++++++++++++---- 2 files changed, 28 insertions(+), 8 deletions(-) diff --git a/coregrind/vg_scheduler.c b/coregrind/vg_scheduler.c index 0e2ce294b6..3750398471 100644 --- a/coregrind/vg_scheduler.c +++ b/coregrind/vg_scheduler.c @@ -33,7 +33,7 @@ #include "valgrind.h" /* for VG_USERREQ__MAKE_NOACCESS and VG_USERREQ__DO_LEAK_CHECK */ -/* BORKAGE/ISSUES as of 23 May 02 +/* BORKAGE/ISSUES as of 29 May 02 - Currently, when a signal is run, just the ThreadStatus.status fields are saved in the signal frame, along with the CPU state. Question: @@ -49,9 +49,6 @@ specified and they are interrupted by a signal. nanosleep just pretends signals don't exist -- should be fixed. -- Read/write syscall starts: don't crap out when the initial - nonblocking read/write returns an error. - - So, what's the deal with signals and mutexes? If a thread is blocked on a mutex, or for a condition variable for that matter, can signals still be delivered to it? This has serious consequences -- @@ -60,6 +57,19 @@ - Signals still not really right. Each thread should have its own pending-set, but there is just one process-wide pending set. + TODO for valgrind-1.0: + +- Check memory permissions of client-space addresses passed from + vg_libpthread.c. + + TODO sometime: + +- Mutex scrubbing - clearup_after_thread_exit: look for threads + blocked on mutexes held by the exiting thread, and release them + appropriately. (??) + +- pthread_atfork + */ diff --git a/vg_scheduler.c b/vg_scheduler.c index 0e2ce294b6..3750398471 100644 --- a/vg_scheduler.c +++ b/vg_scheduler.c @@ -33,7 +33,7 @@ #include "valgrind.h" /* for VG_USERREQ__MAKE_NOACCESS and VG_USERREQ__DO_LEAK_CHECK */ -/* BORKAGE/ISSUES as of 23 May 02 +/* BORKAGE/ISSUES as of 29 May 02 - Currently, when a signal is run, just the ThreadStatus.status fields are saved in the signal frame, along with the CPU state. Question: @@ -49,9 +49,6 @@ specified and they are interrupted by a signal. nanosleep just pretends signals don't exist -- should be fixed. -- Read/write syscall starts: don't crap out when the initial - nonblocking read/write returns an error. - - So, what's the deal with signals and mutexes? If a thread is blocked on a mutex, or for a condition variable for that matter, can signals still be delivered to it? This has serious consequences -- @@ -60,6 +57,19 @@ - Signals still not really right. Each thread should have its own pending-set, but there is just one process-wide pending set. + TODO for valgrind-1.0: + +- Check memory permissions of client-space addresses passed from + vg_libpthread.c. + + TODO sometime: + +- Mutex scrubbing - clearup_after_thread_exit: look for threads + blocked on mutexes held by the exiting thread, and release them + appropriately. (??) + +- pthread_atfork + */ -- 2.47.2