Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Date: Thu, 20 Apr 2000 22:18:34 +0300
From: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Reply-To: Paul Sokolovsky <paul-ml AT is DOT lg DOT ua>
Message-ID: <7929.000420@is.lg.ua>
To: Chris Faylor <cygwin AT sourceware DOT cygnus DOT com>
Subject: Re[2]: Cygwin 1.1.0 gdb troubles
In-reply-To: <20000419130514.B15213@cygnus.com>
References: <20000419130514 DOT B15213 AT cygnus DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Chris,

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.

    This illustrates whole picture of my writing another Posix layer
from scratch: maybe I really will do better with 20% percents of
functionality, but with rest 80% I will just go thru the lot of burden
to come to things long before done in cygwin. And for some fraction of
those 80% my stuff will remain inferior to cygwin forever.

>>     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?

    Nope, I'm here to communicate on questions interesting to me, one
of them is how to have best Posix layer for win32. Best here means not
only by technical properties, but also by reputation, support,
community size, etc., etc. No need to say that cygwin is closest to
this position and I hope will remain so. And since I'm hacker (or
wannabe, YMMV) I take non-technical merits for granted, being grateful
to Cygnus for providing such wonderful product for cummunity, and
emphasize on its technological properties, hoping to discuss different
ways to solve different problems, which eventually may lead to
improvement of product.

   Well, how I worked around (or going to, it's work in progress)
above three problems with pids:
1. Just negating native pid on win9x. Since 9x pid is pointer to some
process block residing in kernel space (above 0x80000000) xored with
some value 0x7fxxxxxx, result will be positive. It however may be
large, but what to do? Well, it gave me headache with porting ash,
which used short to store pid. However, for the rest of well-mannered
apps which use pid_t it give no problems. Also, it's easy for human.
2. While there's no documented way, there's well documented
undocumented way by using native api.
3. Signal watcher of exec stump process should be told to act as
proxy, forwarding signals from exec() child to fork() parent.

   But I don't tell that above is suitable for cygwin, only that it
allows (does it?) to use almost unchanged native pids as posix pids.
For me, it gives following benefits:

1. Simply less kludging - there're pids provided by system and I use
them.
2. Same pid namespace with native apps - it's possible at least to
SIGKILL native app.
3. No need for mapping superstructures.

   Whether these points would be applicable to Cygwin is for sure
cannot be reasoned out by me. For example, 3 is not applicable, since
Cygwin implements process groups, and since win32 process groups are
rather naive, to implement them there needed superstructures anyway.

CF> Probably the most annoying feature of cygwin for me is that people seem
CF> to be compelled to criticize it while offering only vague generalities
CF> and smug assertions that they could do it better.

    Sorry, you told it before and now I'm personally writing working
code. Unfortunately, not for cygwin ;-(

    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.

    And last note about criticizing at all. It's only my perception,
but I see that mailing list traffic consist of following: discussions
of software ported to Cygwin (not Cigwin per se), then Cygwin-specific
features, then things people overlooked in faq, or which just haven't
made their way to, then thanks. As for criticism, there's not so much
of it to worry about to much. That's probably would be interesting if
noone would care to provide one. Well, I care, maybe to my harm.

CF> Before you offer the standard response of "I'm too busy", just take a
CF> moment to reflect on what that statement means.

    Unfortunately, "busy" will be only half-true in my case. I'm just
too weak and burdened with stupid problems poured at me by place I
live in.

CF> If you are too busy to
CF> actually investigate these "problems" and offer concrete solutions, then
CF> why should I believe that your ideas have any merit whatsoever?  How can
CF> you adequately criticize something that you don't understand?

    But I spend my time understanding, investigating and designing
solutions for these problems. I have drive for that. But coping with
building large foreign systems, submitting patches and argueing
they're really needed requires motivation, which luxury is not
effordable here. So, I just knead my crap in the conner, hoping that
some findings may be interesting for others.

CF> Ah.  The next argument will be that you have already implemented your
CF> own POSIX-on-Windows and know everything that Cygwin did wrong.

    Not everyting. But instead, I know where I'm doing wrong. And
that again and again makes me think that having all in one, confirmed
implementation would be better and regret that I'm noone to do that. But
still, it makes to want to "criticize" in hope that other people will
do that. Myself I just do what I'm best at - hack.

CF>   So,
CF> ok.  I'm willing to listen to how you mapped UNIX signals onto what
CF> Win32 offers.

    I used message queues and PostThreadMessage(). As an extra
feature, it allows to SIGTERM native windowed apps gracefully. But
that's only useful mapping to window messages, since WM_QUIT is only
message which works without explicit window id.

CF>   I'll be interested in hearing how you got exec() working.

      Well, I don't try to write my own PE loader to overlay existing
image ;-)

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).

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.

    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).

CF> I don't consider any of this off-topic for this mailing list.

    Nice to here.

CF>   I envision
CF> that you will probably want to enlighten us all with a series of articles
CF> on how it could all be done better, complete with actual code samples.

    Of course, no. Just sometimes, in the spirit of the moment, I do
write some, probaly awkward, but in no way wanting to be jeering,
message. Something like "am thinkink it is pain in neck. she is...", etc.
;-)

CF> Since this will be a substantial work, I guarantee that I will set aside
CF> a portion of my day, every day to read and analyze what you post.  In fact,
CF> I'm quite looking forward to your submissions.  Although you're probably
CF> too busy to provide cygwin patches, I expect that your insightful articles
CF> will still provide substantial fodder for future cygwin development.

    Hardly substantial, but maybe someone will really be interested.

CF> cgf


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135


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