Re: wxt file-save oddity

[Daniel J S. <dan...@ie...>]

On 11/15/2014 06:56 PM, Allin Cottrell wrote:
> On Sat, 15 Nov 2014, Daniel J Sebald wrote:
>
>> On 11/15/2014 02:36 PM, sfeam wrote:
>>> On Saturday, 15 November 2014 03:07:27 PM Allin Cottrell wrote:
>>>
>>> > On Sat, 15 Nov 2014, sfeam wrote:
>>>
>>> > > On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote:
>>> > > > > On 11/15/2014 11:55 AM, Allin Cottrell wrote:
>>> > > > > > On Sat, 15 Nov 2014, Daniel J Sebald wrote:
>>> > > > > > > On 11/15/2014 11:36 AM, Allin Cottrell wrote:
>>> > > > > > > > I just tried out the file save button in the gnuplot wxt
>>> > > > > > > > window. It
>>> > > > > > > > works nicely... except that I'm seeing a delay of up to
>>> 40 > > > > > > > seconds
>>> > > > > > > > between clicking the button and the file-save dialog > >
>>> > > > > > opening.
>>> > > > > > > > > > > > > > > This is on a lightly loaded system, with
>>> gnuplot > > > > > > > launched via gnuplot -persist<plotfile>.
>>> > > > > > > > > > > > > What operating system?
>>>
>>> > > > > > Arch Linux. No other programs showing odd delays in response.
>>>
>>> > > > Aha. No such problem if I run gnuplot interactively, load > > >
>>> the plot file and display the plot. Then the Save button > > > works
>>> instantly. The loooong delay just happens when > > > gnuplot is run
>>> with -persist.
>>>
>>> > > > > In that case it might be informative to establish where the
>>> > > program is hung/delayed.
>>> > > Fire up gnuplot -persist, determinine its <pid>, then hit
>>> > > the problematic button.
>>> > > While it is in the hung state, from another terminal run
>>>
>>> > > $ gdb -p <pid>
>>>
>>> > > gdb> where
>>>
>>> > > to establish where the code is hung.
>>>
>>> > OK, I'm attaching the output from this.
>>> > Allin Cottrell
>>>
>>> I can reproduce this now, so at least I can investigate as I
>>> find time. No ideas at the moment, other than it may indicate an
>>> interlock failure in the gvfs/dbus library code. We could report
>>> that upstream to gtk, but I am afraid that we would then run
>>> into the problem that upstream development is focused on gtk3,
>>> while the problem is occurring in 2.8. I suppose we could
>>> disable the Export-to-File widget in persist mode, but that
>>> would be unfortunate.
>>
>> I don't see this delay on my system (Gnome, GTK 2.0).
>>
>> If it still works, just slow, I'd say simply display some message
>> "File dialog in persist mode may run slow", the first time the user
>> attempts to save a file. But lets see if there is a bug there first.
>>
>> One thing that I notice is that in the WXT setting (the wrench) there
>> is a check box for persist mode. If launching gnuplot with "-persist",
>> that check box is not checked when I think it should be.
>>
>> If launching gnuplot without "-persist", does using the setting to
>> change the "persist" checkbox also result in a slowdown when trying to
>> save a file?
>
> Here are my results (again, with today's CVS):
>
> 1) I do: gnuplot -persist <plotfile>
>
> The dialog opened by the wxt wrench icon shows the "persist" box
> checked; it always takes a long time for the Save dialog to appear.
>
> 2) I do: gnuplot (interactive) ; then 'load' plotfile
>
> a) If I click the wxt wrench icon, the dialog shows the "persist" box
> checked. If I click the Save icon while the calling gnuplot instance is
> still active, it always works instantly.
>
> (b) If I type 'quit' in the calling gnuplot instance, then try the Save
> icon in the wxt window, sometimes the Save dialog still comes up
> instantly and sometimes it takes ages. I haven't yet determined if
> there's any reliable predictor for the variant behaviors.

OK.  Ethan explained the "atexit" code to me, so I see how that is being 
called.  Again, I can't make this hang on my system at all.

I wonder if there might be a race condition here.  wxt_atexit does a 
fork and Ethan confirmed on his system that is the last thing that is 
happening before a hang.

However, the strange part of this wxt_atexit() code--if I'm 
understanding correctly--is that it appears to suspend the process with 
a signal interrupt and then restart the process in the child.  What if 
that signal interrupt is done asynchronously in the O.S.?  It could be 
that the fork happens/restart happens before the signal interrupt 
filters its way to the processes.

When the hang happens on your system, is the their a daemon in the 
process list or is the gnuplot process active and consuming CPU?

Dan