Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Fri, 21 Apr 2000 11:08:37 -0400
To: Chris Faylor <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re: Cygwin 1.1.0 gdb troubles
Message-ID: <20000421110837.F7931@cygnus.com>
Reply-To: cygwin AT sourceware DOT cygnus DOT com
Mail-Followup-To: cgf AT cygnus DOT com,
	Chris Faylor <cygwin AT sourceware DOT cygnus DOT com>
References: <20000419130514 DOT B15213 AT cygnus DOT com> <7929 DOT 000420 AT is DOT lg DOT ua>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.8i
In-Reply-To: <7929.000420@is.lg.ua>; from paul-ml@is.lg.ua on Thu, Apr 20, 2000 at 10:18:34PM +0300

On Thu, Apr 20, 2000 at 10:18:34PM +0300, Paul Sokolovsky wrote:
>Chris Faylor <cgf AT cygnus DOT com> 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
>ruled out.

Specifically?

>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
>course useful.

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.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com