This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
RE: System-wide mutexes and pthreads
- From: "Robert Collins" <robert dot collins at syncretize dot net>
- To: "'Conrad Scott'" <Conrad dot Scott at dsl dot pipex dot com>
- Cc: <cygwin-developers at cygwin dot com>
- Date: Sat, 15 Jun 2002 21:30:01 +1000
- Subject: RE: System-wide mutexes and pthreads
> -----Original Message-----
> From: cygwin-developers-owner@cygwin.com
> [mailto:cygwin-developers-owner@cygwin.com] On Behalf Of Conrad Scott
> Sent: Friday, 14 June 2002 11:40 AM
> nb. I'm not sure about what happens if the client forks
> halfway through the
> attach code being run, since the attach list would be
> inconsistent, so the
> fork code would need to lock the attach list mutex before it
> could go ahead.
> There's going to have to be some mutex handling in the fork
> implementation
> anyhow if any of the dll code uses mutexes. Also note that
> this will be an
> issue with the current design as well (once it gets mutex'ed that is).
If the client calls fork halfway through, it implies 2 things:
1) The client is using multiple threads.
2) The client is not using atfork() which is the proscribed method for
syncronising multi-threaded programs before forking().
So the answer is: tough. It's not our problem.
> So: two proposals: the first is to remove the "control" shared memory
> segment and have the clients make requests for all
> information. The second
> is to strip all the state out of the client-side code, which
> would make it
> thread-safe too :-)
Cool.
> The first seems like a good idea to me, the second is more
> fuzzy. Has anyone
> any opinions on this? Well, anyone who's read this far anyway :-)
Yes, please go ahead. A patch for 1) will be accepted (presuming the
quality is good :}) immediately. For 2) I'd like to see it once 1) is in
HEAD, and review it then.
Rob