Re: System calls without error checks in w32

[Juanma Barranquero]

On Mon, May 31, 2010 at 01:28, Lennart Borgman
<address@hidden> 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