Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Date: Thu, 20 Apr 2000 22:18:34 +0300 From: Paul Sokolovsky X-Mailer: The Bat! (v1.32) S/N AB51B607 Reply-To: Paul Sokolovsky X-Priority: 3 (Normal) Message-ID: <7929.000420@is.lg.ua> To: Chris Faylor 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 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_/ 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