Mail Archives: cygwin-developers/2001/09/17/00:01:29
On Mon, Sep 17, 2001 at 01:29:18PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
>>
>> If we wanted to generalize this then maybe pthread creation could use
>> a DuplicateHandle to store a thread handle in thread local storage.
>> Thread local storage should be pretty lightweight, too. Then acquire
>> could just use the same handle every time.
>
>> Wait. Nope. Then you'd just have a handle leak or a handle race if
>> you closed the handle in pthread_destroy (or whatever it is that gets
>> rid of a pthread).
>
>No, you'd be ok, because thread creation and destruction is not
>serialised. And I don't believe it ever needs to be. You'll also note
>that DuplicateHandle is only called when the ownership changes.
Except you don't know if a thread has been destroyed, the handle closed,
and then a new thread created with the same handle. So, either you
don't close the handles that you created during pthread creation and
suffer a leak or you close them and suffer a race.
>However, unless we use pthreads internally (which should be fine) we
>can't do the above because the pthread code is never hit. We also cannot
>assume that the end user is always using our pthreads :[.
That, I don't really care about. It's the same issue as whether users
want to use read() or ReadFile(). If they want to use ReadFile in a cygwin
program, that's fine but they can't expect signals to interrupt it.
Similarly, if they try to mix pthread mutexes with CreateThread operations
then they deserve what they get.
>So what we need to do is have a static TLS id for the muto class, and
>the muto constructor (using a interlock protected static var) creates
>the TLS id. Then it, and every subsequent constructor stores the Dup'd
>handle (or a pointer there to) there.
Yeah, this is roughly what I think I proposed but I still think it is
not feasible.
(Another thing that I would have liked to have is an "OnThreadExit" function
which could do this kind of cleanup automatically so you wouldn't have
to worry about it.)
>> Anyway, if you can do timings that verify that a muto +
>> DuplicateHandle
>> is faster than a mutex then I don't have any problem with your using
>> the algorithm in pthreads but I don't think I want to deal with the
>> overhead in cygwin itself.
>
>See above :}.
Hmm? I don't get it unless you are talking about using pthreads with
more generic mutos everywhere. I'm not going to use pthreads for the
couple of cygwin threads that are currently in use. There is no reason
to go through any extra overhead for these cases.
But, like I said if we have an interesting replacement for a mutex I
don't mind creating another muto-like object. Maybe it could even
be a new object derived from a muto.
*off-topic alert*
(Btw, Muto was the name of a Superman villain. Actually, I think it was
a Superman of the future villain. This Superman was a decendent of our
latter day Superman. Muto was a yellow-skin guy with a big head. The
future Superman wasn't vulnerable to kryptonite. He was instead vulnerable
to sea water, which must have been sort of an inconvenience.)
(Also, btw, I'm a big Superman/comic book fan.)
*end off-topic alert*
>>One other issue is that I always had a problem with muto creation
>>because if you use normal malloc/free operations they are created prior
>>to fork_child. Then they are immediately overwritten by fork/child.
>>At least I think that is why I used static buffers. I don't exactly
>>remember anymore.
>
>Ok, so we need static muto's everywhere? or can we add a muto to a
>malloc'd class and that will be ok?
Dunno. I haven't given it much thought. I kept trying to come up with
a method for allocating mutos dynamically and failing. But I don't exactly
remember what the problem was. It was easy enough to work around with
static buffers but that's obvioulsy inappropriate for a general purpose
solution.
>>I really wish that Microsoft had given us an open a thread given the
>>thread id function similar to OpenProcess. I think I read somewhere
>>that they actually did have a reason for not doing so but it makes
>>these kind of situations hard.
>
>They did, it's 2k+ only :[. GetThreadHandle (Id) IIRC.
Yeah. I should have qualified that. I remember being surprised to see
that function after having read that they specifically did not provide
this interface previously.
cgf
- Raw text -