On 07/10/2013 20:07, Matthew Brush wrote:
On 13-10-07 08:31 AM, Nick Treleaven wrote:
On 05/10/2013 15:40, Matthew Brush wrote:
On 13-10-05 07:06 AM, Nick Treleaven wrote:
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).
Did we get deadlock with g_spawn? I'm only aware of missing output.
It sounded like what was described by Josh in your link:
"The problem seems to be that pipes are only 4kb buffered by default, so
any process needing to write more than this would block while writing to
stdout and Geany would kill it, as it wasn't reading the pipes until
after the process exited."
But that link is talking about the custom spawning, and provides a patch
to it. You must be confused, g_spawn shouldn't have that issue (only by
coincidence, and I know of no evidence it has).
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?
system() is *synchronous*, so we couldn't remove the SYNC_SPAWN code and
have it as an option.
I mean to remove the win32_spawn function (as it existed before the
system() hack), the one that was left orphaned in win32.c and renamed it
to broken_win32_spawn() that uses the win32 API rather than GLib
spawning or system().
It actually wasn't orphaned if env was set, but I get you.
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] :)
I thought you said it was most important to fix the common case, that's
why I made the PR.
I imagine the most common case would be that g_spawn_async_with_pipes()
works. I've used it a number of times on Windows without issues and I've
not found online or encountered any issues with lost output that's being
claimed as the reason for all these work-arounds for it.
Can you please try running a command that outputs *both* stderr and
stdout? See my reply to the parent message about make object and build.o.
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?
I just tried it. Running build on a C file:
gcc -Wall -c "build.c" (in directory: C:\git\geany\src)
Compilation failed.
gcc: error: "build.c": Invalid argument
gcc: fatal error: no input files
compilation terminated.
No idea why gcc says that, also tried for another file in parent
directory.
Running build on a D file just says 'Compilation failed' without
reporting the line compilation fails on.
Windows Vista. GTK 2.22.0, GLib 2.26.0.
GTK+ 2.22 is over 3 years old by now, FWIW.
OK. Try to reproduce my problem with your newer gtk then.
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
