From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: System calls without error checks in w32 Date: Mon, 31 May 2010 02:58:37 +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 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1275267549 8426 80.91.229.12 (31 May 2010 00:59:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 May 2010 00:59:09 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 02:59: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 1OItLO-0000i0-3i for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 02:59:06 +0200 Original-Received: from localhost ([127.0.0.1]:38042 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OItLN-0003h3-JA for ged-emacs-devel@m.gmane.org; Sun, 30 May 2010 20:59:05 -0400 Original-Received: from [140.186.70.92] (port=33629 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OItLI-0003f9-2z for emacs-devel@gnu.org; Sun, 30 May 2010 20:59:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OItLG-0004FJ-H3 for emacs-devel@gnu.org; Sun, 30 May 2010 20:58:59 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:47608) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OItLG-0004Ez-9t; Sun, 30 May 2010 20:58:58 -0400 Original-Received: by yxs7 with SMTP id 7so385673yxs.0 for ; Sun, 30 May 2010 17:58:57 -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 :content-transfer-encoding; bh=0KGepj83+dQ3nXO9hnA1jQpLi48YI4mWov5VKts4teY=; b=r1Y0mRpKvE2nSKOZ94BbhSVoaWwfbNenRAcHn8h2dWZ0jzt2WBvBCSXthaRTahJ+Hz 4nWOPVCTVCSXrbcGIubdR4W7gIKHBuUN0DiJvb9BGiPR/7H+Rcm4+9rcl1RZ8/M/K3g4 evJ2i2xRCo3/RwpPzFjrBtDsXYnloCcJAwHdo= 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:content-transfer-encoding; b=GbySgmpvSikG3RSFlVD7sn4e0XRd1sZPHRgn5BOHN3pFHrFuJ8gKuqIwE8yx+A3QvJ 2tswMztG1wU3NnIsiYeHywpfrYW7fBZS0VVcS8mqCizPyjKxPRSIsPHWP9yQlUBg6Vmv vwjqRoP+F5/NCqQ9fJHP/XB1ED3FW8mKusjjc= Original-Received: by 10.101.5.18 with SMTP id h18mr3766924ani.120.1275267537263; Sun, 30 May 2010 17:58:57 -0700 (PDT) Original-Received: by 10.100.44.20 with HTTP; Sun, 30 May 2010 17:58:37 -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:125382 Archived-At: On Mon, May 31, 2010 at 2:10 AM, Juanma Barranquero wrot= e: > 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. I don't think so. It is just much more difficult to track some of these. For example I know Drew recently wrote about problems when creating new frames. It is quite hard to both understand what is happening and what is a bug and what is not. Is there just a bad timing? A missing hook to proceed the function etc (you may have to wait until the frame creation is finished)? >> 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. I just mean that the normal C code (i.e. not related to system calls) seems better checked on w32. > Usually, bugs have a tendendy to show up even if you're not looking for t= hem... Maybe you are missing my point. The system tries to stay stable. There are timing issues etc. >> 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). No. I would rather say I just don't have time then. When I entered this list I went into a long discussion about the problems with printing on the w32 side. I actually felt I wasted a lot of time when I told that the code was in error. Since then I have thought it is less waste of time to keep the patches in my patched version. Now and then I ask if things have changed. If they have not I just skip it, but with some regret about the extra trouble and lost work. >> 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 :-) Yes, it seems easier, but I will have to create quite a few branches for some old patches. And it takes time. >> 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. Thanks. Yes, of course. >> Both ;-) > > Well, if you know there are troubles, you can patch your Emacs and debug = them... See above. >> 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. I have done that many times (or sent reports to the list before) but these kind of errors are not easy to track down. And since I have some patches (that correct some bugs, but also makes other bugs more visible) they tend to be dismissed. It is kind of a locked situation. > 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. There are a lot of them as I said before. >> 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? It seems much more trouble reporting the problems than fixing them. Maybe I should try to make a "system calls fix branch" from savannah and pick them one by one when I have time. >> 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. I have an example where I create a frame contact a web page in pause.el. Is that specific enough? (You have to run my patched code to see it since I can't do the frame manipulation I need without that.) >> Oh, the four args where just to make it more easy to understand... ;-) > > I think you mean s/more/less/. No ;-) >> 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). I don't think so. You should most often not crash Emacs because of bad system call return status. You should take a relevant action. >> 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. Of course, but you may be interested in information about what happened too= . >> 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 > ;-) Perhaps not, but sometimes it is a bit scary when merging as it was recently when I had some changes to local/global variables. A variant of those are now in Emacs so I can skip worrying about that any more. And the changes that allows better menu handling are also a bit scaring when merging. They are still only in my code. > =C2=A0 =C2=A0Juanma