From: Juanma Barranquero <lekktu@gmail.com>
To: Lennart Borgman <lennart.borgman@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: System calls without error checks in w32
Date: Mon, 31 May 2010 02:10:14 +0200 [thread overview]
Message-ID: <AANLkTimb2-F9xdfX8H4aMuxhDX8JOgNN9J2p1Xm9KDrj@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimzyxDoUA2_YYljPQadg05X4yV47BX1PMtO4nWz@mail.gmail.com>
On Mon, May 31, 2010 at 01:28, Lennart Borgman
<lennart.borgman@gmail.com> 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
next prev parent reply other threads:[~2010-05-31 0:10 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-29 2:38 System calls without error checks in w32 Lennart Borgman
2010-05-29 17:43 ` Eli Zaretskii
2010-05-29 18:42 ` Lennart Borgman
2010-05-29 19:35 ` Eli Zaretskii
2010-05-29 20:02 ` Lennart Borgman
2010-05-29 21:25 ` Eli Zaretskii
2010-05-29 21:30 ` Lennart Borgman
2010-05-30 3:02 ` Eli Zaretskii
2010-05-30 3:26 ` Lennart Borgman
2010-05-30 17:36 ` Eli Zaretskii
2010-05-30 18:02 ` Lennart Borgman
2010-05-30 19:24 ` Juanma Barranquero
2010-05-30 22:37 ` Lennart Borgman
2010-05-30 23:03 ` Juanma Barranquero
2010-05-30 23:28 ` Lennart Borgman
2010-05-31 0:10 ` Juanma Barranquero [this message]
2010-05-31 0:58 ` Lennart Borgman
2010-05-31 2:02 ` Juanma Barranquero
2010-05-31 2:36 ` Lennart Borgman
2010-05-31 3:06 ` Juanma Barranquero
2010-05-31 3:05 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2010-05-31 9:18 grischka
2010-06-05 17:15 ` Jason Rumney
2010-06-07 10:37 ` grischka
2010-06-07 14:54 ` Stephen J. Turnbull
2010-06-07 15:23 ` Lennart Borgman
2010-06-07 17:21 ` grischka
2010-06-07 17:30 ` Lennart Borgman
2010-06-07 18:54 ` grischka
2010-06-08 0:32 ` Lennart Borgman
2010-06-08 0:34 ` Lennart Borgman
2010-06-07 19:56 ` Stefan Monnier
2010-06-07 23:35 ` Lennart Borgman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimb2-F9xdfX8H4aMuxhDX8JOgNN9J2p1Xm9KDrj@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lennart.borgman@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).