This is the mail archive of the
mailing list for the Cygwin project.
Re: Cygwin 1.1.0 gdb troubles
- To: Chris Faylor <cygwin at sourceware dot cygnus dot com>
- Subject: Re: Cygwin 1.1.0 gdb troubles
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Fri, 21 Apr 2000 11:08:37 -0400
- References: <20000419130514.B15213@cygnus.com> <email@example.com>
- Reply-To: cygwin at sourceware dot cygnus dot com
On Thu, Apr 20, 2000 at 10:18:34PM +0300, Paul Sokolovsky wrote:
>Chris Faylor <firstname.lastname@example.org> wrote:
>>>difference: remove() explicitly states possibility of removing opened
>>>file, while DeleteFile() explicitly prohibits it. I can't believe
>CF> So, how do you work around this tiny little flaw then? How does your
>CF> magic wand work?
> Bad metaphor, it's for sure not magic, just pure technology, and
>hardly can be considered sufficiently advanced. So, currently I just
>ignore such error condition. So, after typical configure session with
>bash tens of orphaned files lie in /tmp. That sucks. I already made
>support for close-on-exec, but instead of set of flags I used array of
>fds which need to closed. So, one sweet day I will re-make it as
>arrays of flags, add new should-be-deleted on close flag to it. Then,
>close() will check that flag and delete that file. Well, but how I
>will get filename to delete? I know of no way to get it by handle, and
>I'm not going to store filename for each opened file.
Doesn't that sort of discount your assertions that it could all be done
much more easily using simple Win32 calls?
>>>Well, what idiosyncratic features of native pids would harden
>>>their usage as POSIX pisd as-is?
>>>1. While NT's pids are rather POSIX-correct as-is, 9x's ones are
>>>negative values, large (up to 10 dec digits) by module.
>>>2. There's no documented way to get ppid on NT.
>>>3. It's impossible to overlay image of current process. This means,
>>>when performing usual fork-exec chain, there will be three processes:
>>>parent, exec() implementer stub and execed child. So, between child
>>>and parent in POSIX terms there will be other process.
>CF>I'd like to hear your workaround for these problems. Really. I'm eager
>CF>to incorporate your advanced thinking into cygwin's design. Or are you
>CF>just here to poke fun and jeer?
> Well, how I worked around (or going to, it's work in progress)
>above three problems with pids:
>2. While there's no documented way, there's well documented
>undocumented way by using native api.
This was the gold I was trying to mine. What's the "undocumented" way of
using the native API?
>3. Signal watcher of exec stump process should be told to act as
>proxy, forwarding signals from exec() child to fork() parent.
So you have two processes for every exec. Ouch.
>But whole point is not correct imho. For example, I see that Cygwin
>improves with each release, moreover misfeatures which annoyed me
>personally (as well as some other people, of course) are lifted. That
>means that you listen to what people say and that's specific enough to
>work out. Also, whenever I take a look at develop archives, I see
>sufficiently enough new features proposed. Unfortunately, some are
>CF> You probably have implemented a fork. I'd be interested in hearing how
>CF> it differs substantially from what cygwin offers.
>It doesn't engage in long chats between parent and child. Parent just
>prepares everything, starts child, sleeps, child clones memory and
>awakens parent. Keeping in mind that it has no support for dlopen'ed
>modules, its about 40% faster that cygwin's (not so bif figure, imho).
This is just about the same as what cygwin does. I don't know where you
got the idea that there are "long chats" between the parent and the child.
>CF> Hmm. You disparage
>CF> the cygwin mount table. Let's hear how you have tackled this problem.
> I disparage not mount table, but way it was automatically setup in
>up to b20. While I personally don't use it, many people do since it's of
There is actually no difference in the net release, AFAIK.
>What I really can give criticism for is /cygdrive/ syntax. Reason for
>that is simple - that "cygdrive" is path component but *do not* maps to
>anything real in underlying file system. Some programs traverse path
>themselves, statting each component. Proverbial ash is example. So,
>to make it work it either requires to patch app itself or provide
>workaround in libc. That won't happen if you've chosen other syntax.
>As I did, I support /cygdrive/ syntax but it's deprecated, and
>/mnt_<drive>/ is recommended (btw, 'mnt_' part is not changable, I
>don't want incompatibilities between installations).
You're welcome to create /cygdrive if that is a problem or change /cygdrive
to /mnt, if that's an issue.
Anyway, you're describing a bug which can be fixed. Thanks for reporting it.
Want to unsubscribe from this list?
Send a message to email@example.com