Please describe the problem:
When running the function vte_terminal_feed_child an race occurs which leads
to vte not placing a "watch" for the G_IO_OUT channel. This leads to Vte not
accepting input for the child process. (That is, Vte freezes)
( I wrote about this in bug nr 117945, but I'm not sure it was the same bug)

Steps to reproduce:
1. build an application with a vte terminal
2. run vte_terminal_feed_child()
3. run vte_terminal_feed_child()



Actual results:
The 2. call (and any subsequent calls) to vte_terminal_feed_child() don't do
anything

Expected results:
Input should be fed to the child process

Does this happen every time?
On some platforms yes, on others no.

Other information:
The problem seems to lie in src/vte.c file with the
terminal->pvt->pty_output_source variable. In the function
_vte_terminal_connect_pty_write() the pty_output_source-variable
is assigned the return value of the function g_io_add_watch_full().
The race happens when the callback registered by g_io_add_watch_full()
gets called before g_io_add_watch_full() returns. 
The callback function (eventually) calls  _vte_terminal_disconnect_pty_write(),
which shall set terminal->pvt->pty_output_source to VTE_INVALID_SOURCE.
But since terminal->pvt->pty_output_source isn't set to the return value of
g_io_add_watch_full(), it doesn't get cleared, and hence, will remain with the
value eventually returned by  g_io_add_watch_full(). This value then prevents 
_vte_terminal_connect_pty_write() from ever setting an other GIO-watch, and thus
vte will not send any data to the child.

Protecting terminal->pvt->pty_output_source with a mutex seems to make the race
dissappear (but it's hardly an optimal solution?)