On May 07, 2007, at 22:49:04, Ulrich Drepper wrote:
On 5/7/07, Davide Libenzi <[email protected]> wrote:
read(2) is a cancellation point too. So if the fine userspace code
issues a random pthread_cancel() to a thread handling that, data
is lost together with the session that thread was handling.
This is absolutely not comparable. When read/write is canceled no
data is lost. Some other thread might have to pick up the slack
but that's it.
Uhh, how can you claim "no data is lost" in this scenario:
A bunch of threads shares a common fd and fpos, reading fixed-size
records:
thread1: read(myfd, per_thread_buf, 512);
thread2: pthread_cancel(thread1);
thread3: read(myfd, per_thread_buf, 512);
This is *exactly* analogous to the epoll() scenario: A bunch of
threads are attempting to get data (either events or records) from a
given object. If thread1 gets cancelled after the completion of its
read() syscall then the file position will have been advanced but the
data in the per-thread buffer will be discarded. The third thread
won't (reliably) get the same data as thread1. It might get it
randomly on occasion if file position updates race, but you can't
rely on that behavior.
Here's how you make both of those models safe against thread
cancellation (assuming, of course, that process_one_buf has no
cancellation points until after it saves the buffer state somewhere):
char per_thread_buf[512];
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
while (read(fd, per_thread_buf, 512) == 512) {
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
process_one_buffer(per_thread_buf);
pthread_testcancel();
pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
}
pthread_exit(NULL);
Look how trivial that is! Isn't it fun? Of course, once you look at
it this way you could do the same verbose crap that pthread_cancel/
pthread_setcancelstate/pthread_testcancel are doing with a simple int
protected by a pthread_mutex.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
