emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: System calls without error checks in w32


From: Juanma Barranquero
Subject: Re: System calls without error checks in w32
Date: Mon, 31 May 2010 01:03:06 +0200

On Mon, May 31, 2010 at 00:37, Lennart Borgman
<address@hidden> wrote:

> Yes, my intention was not to add them everywhere, only on interesting places.

It didn't seem so in your first message.

> On a quick look I got the impression that file calls are better
> handled than GUI system calls.

Likely because file calls are much more likely to fail.

> It happens to me with my patched Emacs because that is the one I am
> using. I only use unpatched Emacs for bug testing etc.

Why don't you add these checks to your patched Emacs and see what comes of it?

> That is surely true, but I am not comfortable with how threads are
> integrated (i.e. it is not visible enough IMO). I wonder if there are
> any troubles there. Those threads of course communicate through system
> calls.

Do you wonder where "there are any troubles there", or do you suspect
that there are troubles?

> I might have fixed some of the problems with related to frames which
> calls crashes, but there might be more.

Well, perhaps you've fixed them, but as I've said, your Emacs seem to
crash more often than most others ;-)

> And I wonder why Emacs sometimes seems to hang temporarily when frame
> related operations are going on. Is something going wrong?

You'd have to be a bit more specific...

> And the inability to stop Emacs sometimes is quite disturbing. What is
> going on there? Why does not the GUI thread get resources? Or is it
> given resources but a block occur in some other way? Is GUI messages
> not checked when looping?

Also here.

> This type of entering the checks is very
> similar to what `assert' does in Emacs. Does that mean you think
> `assert' is very ugly too or is there some difference I am missing?

No, I quite like asserts. The difference is than assert is

  assert (some test)

There's nothing to understand there. It passes, or it fails.
W32DEBPRINT has four arguments; at the very least, if would make more
sense to do

   W32DEBPRINT (this_function, ApiFunction (args) != bad_return_value)

or somesuch, and, at that point, you're just reinventing assert, which
seems pointless.

Anyway, my feeling is that it makes much more sense to check return
codes *to do something* about them in the case of failure, that just
to print a message which will be helpful or not, depending of how
frequent / how informative they are. So if you're really interested in
doing this, I'd suggest looking at specific unchecked syscalls and
trying to determine if something (could / need to) be done in case of
error. And then send patches ;-)

    Juanma



reply via email to

[Prev in Thread] Current Thread [Next in Thread]