[Geany-Devel] Ping on Bug #943 - windows build command

[Matthew Brush]

On 13-10-05 07:06 AM, Nick Treleaven wrote:
> On 05/10/2013 14:59, Nick Treleaven wrote:
>>>> spawn that doesn't block Geany or outright hang. This definitely
>>>
>>> It would be nice to figure out *why* it was hanging and fix *that*
>>> problem though, not just drop the existing workaround code and write 3rd
>>> workaround that's arguably worse[1] than the original issue.
>>
>> I did try.
>
> In fact I wasted about a week trying to fix it, reading windows API
> docs, reading forum threads etc.
>

Ugh, been there, I feel for ya :)

>>>> happened very frequently when using dmd from dlang.org. See:
>>>>
>>>> https://github.com/geany/geany/commit/a3664fae9ece396952d732cc937e63192d8c6f76
>>>>
>>>>
>>>>
>>>>
>>>
>>> I don't remember seeing any bug reports for this, so it's possible it's
>>> limited to you or the specific application you were using, maybe a bug
>>> in a certain version of DMD? The commit messages doesn't explain what
>>> the actual root of the problem was or why it could not be fixed
>>> properly, or what was tried to fix it before abandoning the existing
>>> code.
>>
>> It was last year, but I think it wasn't just with dmd, although that
>> triggered it the most, and it only happened when dmd wrote more than a
>> certain amount to stderr (cascading errors). It was very suspicious that
>> the custom spawn code works until there are too many errors, at least
>> with dmd.
>
> One person reported it on the devel list. See:
> http://lists.geany.org/pipermail/devel/2011-July/004845.html
>
> Unfortunately I missed that mail at the time, but I tried the provided
> fix before committing my system() change, and I remember it didn't fix
> all the issues with blocking and/or hanging Geany I had.
>

That was going to be my guess for the deadlock, once the buffers fill up 
they have to be drained or else can't keep writing to input. The same 
issue should apply to any spawning method we use probably (ie. GSpawn).

So with the pull request adding system() as a fallback/hidden 
preference, maybe we could just drop the win32 API code altogether, 
switch back to using the same codepath as all platforms (ie. GLib async 
spawning) and if people experience issues, we can use as further data 
points to troubleshoot GLib async spawning and we can recommend they try 
the system() option[1] as a workaround?

IMO, any function in our code base prefixed with _broken, that no one 
wants to touch, and looses platform-independence for our code, should 
just be deleted[2] :)

BTW, did you try undefining SYNC_SPAWN lately to see if async spawning 
still doesn't work for you now? If so and it doesn't, what Windows 
version and GLib versions do you have?

Cheers,
Matthew Brush

[1]: And maybe fix it so it does cmd.exe quoting properly.
[2]: Of course it's in Git history so if async spawning ends up not 
working for many people we can always put it back later.