lkml.org 
[lkml]   [2002]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] threading enhancements, tid-2.5.47-C0
Ulrich Drepper wrote:
> > (That said, I'm not entirely convinced that blocking signals in cfork()
> > is so bad, if we assume that cfork() is a relatively expensive
> > operation anyway...)
>
> It could mean a signal cannot be delivered and reacted on in time. The
> other threads could have blocked the signal which arrives. Every time
> signals have to be blocked to implement a function something is wrong,

I don't buy this argument. You block signals, do something, unblock
signals. There may be a _tiny_ delay in delivering the signal - of
the order of a single system call time, i.e. not significant. (That
delay is much shorter than signal delivery time itself). No signals
are actually _lost_, which would be important if it could happen.

Blocking signals briefly is very similar to taking a spinlock. It has
a small overhead, which is probably not significant in the case of
cfork() and its likely applications.

Regarding whether clone() needs a separate child tid_address pointer -
I have no strong opinion (you can implement cfork() with or without),
but you might want to consider, from Glibc's perspective, that there
aren't many argument words left for future uses..

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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