From: Lennart Borgman <lennart.borgman@gmail.com>
To: Juanma Barranquero <lekktu@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:58:37 +0200 [thread overview]
Message-ID: <AANLkTilZjww4ThFzZCfHnyitzvDSLX96vu2JTU2b2YOK@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimb2-F9xdfX8H4aMuxhDX8JOgNN9J2p1Xm9KDrj@mail.gmail.com>
On Mon, May 31, 2010 at 2:10 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> 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.
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 them...
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.
> Juanma
next prev parent reply other threads:[~2010-05-31 0:58 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
2010-05-31 0:58 ` Lennart Borgman [this message]
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=AANLkTilZjww4ThFzZCfHnyitzvDSLX96vu2JTU2b2YOK@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@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).