Subscribe to this thread
Home - General / All posts - Hang on clipboard
tjhb
10,094 post(s)
#09-Feb-18 00:19

It's really not good, either in Manifold 8 or in 9, if we have more than one instance of Manifold open, and if one of the instances is busy, and we copy something to the clipboard (in any application), that the 'free' instance(s) of Manifold will hang until the busy instance has processed the clipboard operation.

It can be many many minutes. Tens of minuites.

(10s would be OK.)

tjhb
10,094 post(s)
#09-Feb-18 00:37

...though it always comes back eventually.

(The busy project was loading a drawing of about 838 million points. It is now rendering, and the free instance is now available again.)

(Now I have zoomed in and out, so it must re-render, which is fine, but I dare not use the clipboard again until it has finished.)

tjhb
10,094 post(s)
#09-Feb-18 00:49

Now saving the large file (making it busy, fair enough) means that if I use the clipboard (in any application), all other instances of Manifold become unresponsive.

Other apps remain responsive and are fine.

rk
621 post(s)
#09-Feb-18 07:11

Yes, I have an Ironpython script running for several minutes and Ctrl-C made all instances unresponsive.

adamw


10,447 post(s)
#10-Feb-18 14:22

We'll check what we can do, but in general this is unsolvable for copies (solvable for pastes), because the alternative is worse.

Clipboard is a resource that is shared between processes. The protocol for using the clipboard is this: open clipboard - take some data from it or put some data into it - close clipboard. If some application is working with the clipboard, other applications cannot open it.

This poses a conundrum when copying big amounts of data into the clipboard: do we (a) start by opening the clipboard and then go on and copy the data, making the clipboard unavailable to other applications for minutes, or do we (b) prepare the data beforehand, and then try to put something like a link to it into the clipboard, which will only hold the clipboard busy for a couple of milliseconds?

Before you say that of course it has to be (b), consider that after you prepared the data, the attempt to put a link to it into the clipboard might fail. Because, again, some other application might be holding the clipboard open. So, the user clicks Copy, we spend minutes collecting the data, then we come to the clipboard and it is busy. What now? Not only is the clipboard busy, there is no telling when it will become available. And we don't know why the clipboard is busy either. Maybe the user started copying something else but maybe that's just some application checking what the clipboard contains and it is just being slow. So we can perhaps retry putting the data into the clipboard several more times automatically, but eventually we will have to stop trying and throw the data we spent so much time collecting away. This is, of course, bad, because we spent minutes collecting the data and this time was wasted. The user will have to try clicking Copy again and we will have to spend more minutes collecting the data again and pray that the operation will succeed in the end.

Because of that, everyone just does (a) and when it is slow, oh well, then it is slow and the clipboard is unavailable until the operation completes. The polite (b) is just hard to make work. The clipboard protocol needs to be more sophisticated to allow the polite (b).

There are still things we can do to avoid the hangs and we will do them. But in general, when you copy a lot of data from 9, *other* applications might become unresponsive and there is nothing we can do about it.

tjhb
10,094 post(s)
#11-Feb-18 01:57

Well, I think that is not the point. Unless I am missing some overlap, I have no complaint about that scenario.

That is, when Manifold (8 or 9) copies a large amount of data to the clipboard, it seems fine(ish) for other applications, including other Manifold instances, to be prevented from accessing the clipboard, and perhaps to go unresponsive if they repeatedly try to do so.

The same in reverse. If another application copies a large amount of data to the clipbaord, then it seems fine(ish) for Manifold applications (8 or 9) to be kept waiting while that is done.

To improve on those things, someone named Microsoft would perhaps have to update the Windows Clipboard beyond the late 1990s.

But none of that is the issue.

The issue I tried to describe is much more annoying, much more obvious, and specific to Manifold.

Step by step might be clearer. I'm going to stick to Manifold 9, but the same think applies to Manifold 8, or a mix of 8 and 9.

  • Open Manifold 9, instance A. Load some data.
  • Begin a long operation in instance A...
  • Open Manifold 9, instance B. Take no action for now--but this instance is initially live and responsive.
  • Open (say) Notepad++ with some text. Copy anything (even one character) to the clipboard.
  • Now Manifold 9, instance B, immediately becomes unresponsive.
  • Instance B remains unresponsive and inaccessible until instance A has finished its long operation (and becomes responsive itself). That could be a very long time. Tens of minutes is not uncommon.

(An obvious question: how about if I launch a third instance of Manifold 9 at this point? Is it immediately accessible or inaccessible? I need to re-test that.)

(Another obvious question: had instance A previously used the clipbaord itself?. If so, what type of data did it copy? I need to check.)

I will try to refine these steps, with some data to reproduce the issue reliably.

adamw


10,447 post(s)
#13-Feb-18 07:11

This does look wrong, indeed. We'll try to reproduce and fix it.

Thanks!

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.