From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: System calls without error checks in w32 Date: Mon, 31 May 2010 02:10:14 +0200 Message-ID: References: <83ocfytxhg.fsf@gnu.org> <83mxvitsay.fsf@gnu.org> <83ljb2tn6i.fsf@gnu.org> <83k4qmt7lb.fsf@gnu.org> <83hblpthpt.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1275265029 3385 80.91.229.12 (31 May 2010 00:17:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 00:17:09 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 02:17:07 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OIsgk-0000es-Hh for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 02:17:06 +0200 Original-Received: from localhost ([127.0.0.1]:59646 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIsgj-0000kj-AI for ged-emacs-devel@m.gmane.org; Sun, 30 May 2010 20:17:05 -0400 Original-Received: from [140.186.70.92] (port=48595 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIsgc-0000jx-Qf for emacs-devel@gnu.org; Sun, 30 May 2010 20:16:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIsaR-0008Rn-QG for emacs-devel@gnu.org; Sun, 30 May 2010 20:10:37 -0400 Original-Received: from mail-fx0-f41.google.com ([209.85.161.41]:34899) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIsaR-0008Ra-J3; Sun, 30 May 2010 20:10:35 -0400 Original-Received: by fxm11 with SMTP id 11so2573406fxm.0 for ; Sun, 30 May 2010 17:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=hjgmEEYeedxR4W+QnFpdnEtgMP55841WGMsrhvhQ4+0=; b=x2fBB4EMiIuIwcIHYZZZAu7WzRth1AeXG50s6ZDf/hJBcJ3aDtL+/VjwLyA9oCAqLH B1o+Q7h4qcBqhBpqxAs9XHGGZwkCWRLJO2Im3a03WADv3aE8hIbIZdGFctVCCUmGlfqW KvQmo0mVg0O6KhtM4RLlyLnrTuHA4V9mfyYFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ttUhih459S0HLmrHtzk02j27PWUFcNYe9GlQ6gwJ1E6BhqiWixgrjNA17Rd+xpawqX wS7oYL4+SioEZvt5ak3fW+os6VpBwrcAbUU3MAy0D+VP/EwoqsaBP+zlSj8XDPMSRuaz PJluS+72NYd8F5q+7FegvzXXRDilQvfxHYrV8= Original-Received: by 10.102.211.40 with SMTP id j40mr1450971mug.69.1275264634219; Sun, 30 May 2010 17:10:34 -0700 (PDT) Original-Received: by 10.204.32.18 with HTTP; Sun, 30 May 2010 17:10:14 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125378 Archived-At: On Mon, May 31, 2010 at 01:28, Lennart Borgman wrote: > That is not what I think. I think instead that the consequences of > failing file calls are more visible and therefor much easier to catch. They wouldn't be catched if they didn't happen. If other system calls are causing as many errors as you suggest, it is strange the sparsity of bug reports about them. > And it looks to me from the code that the knowledge of other system > calls is less or at least more problematic to handle. I cannot parse this, sorry. > At least on the > w32 side. And it is not surprising since we are few here looking at > that code. That is also one reason for adding debug calls since it can > give more knowledge of what is going on in that code. Usually, bugs have a tendendy to show up even if you're not looking for them... > It takes me quite a lot of time to take care of all the patches. There > does not seem to be much interest or time to fix many of the issues > and then I have to keep them in my patched version. Here we go again. "Does not seem to be much interest or time" sort of implies that you've done the work of sending patches and they've been summarily rejected. From my recollection, you seem to lose interest quite fast as soon as you fail to immediately convince that they are worthwhile and correct (sorry if this seems an ad hominem; it's not. I'm just describing how I remember past interactions, particularly with respect to emacsclient). > Also it is much more trouble making a patch later if I have a lot of > small patches that are not in the upstream Emacs. That's what branches are for :-) > One reason is of course that I do not install my patches myself. Maybe > it is time to do that instead. Is there any easy way out of the > situation that I have my checkout from Launchpad. Can I somehow make > bzr aware of that this is really the same thing as on savannah and > upload from it? Or should I make a new checkout from savannah and use > that just for this? The latter. But I'd advise against installing these kind of changes without discussing them first with Eli and Jason, which shoulder most of the w32 effort. > Both ;-) Well, if you know there are troubles, you can patch your Emacs and debug them... > How does blocking interfere with that code? Are the system calls > always done in the right thread (or with correct thread > communication)? Again: for specific problems, file bug reports. Perhaps there are really some missing checks on some syscalls, but the fix for your troubles is likely to be more than just calling DebPrint. > I think I have given the reason for that. So far I have never been > able to identify a crash as something depending on my code. Have you been able to identify them as something depending on the trunk code? If so, did you file reports for them? > I see this when creating a frame in a timer. Or perhaps when fetching > info from the web in a timer. I am not sure, but none of these should > block. > Of course there must not be system calls involved directly. It might > be "bad chaining", i.e. code that is unnecessarily waiting for system > calls to complete. Specific examples would help in debugging this. > Oh, the four args where just to make it more easy to understand... ;-) I think you mean s/more/less/. > Do you mean there is an assert that can do DebPrint? That would be very nice. No, I mean that if the syscalls are failing in such a way that there's no fix to be done after the fact, triggering an assert is the Right Thing To Do (that will help detect the problem). > Things sometimes does not go totally wrong with system calls even if > something is wrong because the system will try to recover. Looking at > the messages might then give some information. That is not an argument *for* printing information, is an argument for checking the return code more thoroughly and doing the right thing. > Sending patches is much easier if you do not have to remove a lot of > things from the diffs. Do you really have so many changes in the w32*.c files that doing a diff is a problem? Perhaps it's time you start calling EmacsW32 a fork ;-) Juanma