Re: Problem with locked files - solved (inheritable handles)
From: Tom Stewart (tastewar_at_newsgroups.nospam)
Date: 06/11/04
- Next message: Joe Hagen: "Re: Problem with findfirst/findnext functions"
- Previous message: Don Burn: "Re: Problem with locked files - solved (inheritable handles)"
- In reply to: Don Burn: "Re: Problem with locked files - solved (inheritable handles)"
- Next in thread: Gary Chanson: "Re: Problem with locked files - solved (inheritable handles)"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 11 Jun 2004 09:43:18 -0400
Sorry, Don, but you are missing the most important point, which in my view is how one might solve Dylan's specific
problem. I *do* understand how handles work. If you look more carefully at my suggestion, all it does is change what's
passed in to CreateFile on a per-thread basis. I didn't make any claim about a thread association of handles. If you
also look back at the original post, Dylan states, "The secondary process does need to inherit some handles (because I
redirect its input and output), but it certainly shouldn't be inheriting every single file handle opened by the process,
and specifically not those from other threads." Seems to me that in his design (and likely many others) that while
threads are indeed *valid* throughout a process, that in practice they are often *used* only by a particular thread. I
still think that my suggested change to the crt would accomodate Dylan's design. Specifically, the thread that he uses
to create child processes would create inheritable handles. The other threads would create non-inheritable handles via
the proposed function call. Remember, he's already implemented an effective workaround at the application level, it's
just that it was uglier than he wanted and required him to delve into Win32 to call CreateFile directly, which
apparently he preferred not to. I was only offering that a cleaner workaround could be implemented in the library, and
only as an intellectual exercise really.
-- Tom "Don Burn" <burn@stopspam.acm.org> wrote in message news:10cj9ifd9m5lla2@corp.supernews.com... > > "Tom Stewart" <tastewar@newsgroups.nospam> wrote in message > news:elYWR26TEHA.3140@tk2msftngp13.phx.gbl... > > Sorry, but impossible is a very strong word, esp. in the world of > software. > > > > Seems to me the CRT could be changed pretty trivially to accomplish this > in a backward compatible manner. Scheme goes > > something like this: > > > > New CRT function: > > > > MicrosoftSpecificCRTSetThreadPrefs ( DISALLOW_HANDLE_INHERITANCE, TRUE ); > > > > This would set a thread specific flag, internal to the CRT that would be > taken into account in all CreateFile calls. If > > you don't set the flag, the function behaves as it always did. Dylan would > call this (if his code is intended to be > > platform neutral, it would be in some ifdef block) for all threads other > than the one which creates child processes. > > > > Am I missing something? I'm not suggesting that they'd actually be willing > to *do* this, or even that it would > > necessarily be useful outside of Dylan's design, but it doesn't seem that > hard. > > > Yes you are missing the most important point. Handles are stored on a per > process basis! There is absolutely no association of a thread and a handle, > only a process and a handle. Changing this would impact the OS, break many > programs, and even break a reasonable number of device drivers. > > > -- > Don Burn (MVP, Windows DDK) > Windows 2k/XP/2k3 Filesystem and Driver Consulting > Remove StopSpam from the email to reply > >
- Next message: Joe Hagen: "Re: Problem with findfirst/findnext functions"
- Previous message: Don Burn: "Re: Problem with locked files - solved (inheritable handles)"
- In reply to: Don Burn: "Re: Problem with locked files - solved (inheritable handles)"
- Next in thread: Gary Chanson: "Re: Problem with locked files - solved (inheritable handles)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
