Re: System calls without error checks in w32

[Lennart Borgman]

On Mon, May 31, 2010 at 2:10 AM, Juanma Barranquero <address@hidden> wrote:
> 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.


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