Serialization/deserialization problems (atom-domterm)


#1

I created the atom-domterm terminal emulator package, which delegates all the complications of terminal emulation and session (pty) management to a separate 'domterm` backend (server). The basic functionality of atom-domterm works well, but are problems with session/lifetime management.

Atom seems to call “serialize” at times when I wouldn’t expect it to - for example when resizing by dragging a splitter. I’m having difficulties understanding when the serialized state is used, and when it is discarded. Note that for a terminal emulator there is external state that must be managed: The process id and the pty. (You can’t depend on garbage collecting the serialized state.) In atom-domterm this is managed by the domterm backend - which does know how to request and restore serialized sessions. However, it is essential that the backend know when a session is serialized and detached - vs when the session exits. The latter can happen because the user clicks on a close button - or because the shell process exits.

Bottom line: I (and presumably other Atom terminal emulators) support 3 operations: serialize and detach; deserialize and attach; and exit session. I haven’t figured out the correct way to map Atom events to these 3 operations. Part of the problem may be that I probably haven’t hooked up deserialization properly - even though dragging domterm panes does (sometime) work.


#2

The reason why serialize gets called constantly is to store the current state of Atom’s window in case it suddenly closes and needs to be restored. You should treat detach separately from serialize, and just assume that Atom’s saving data every chance that it gets.


#4

Thanks. I can certainly have serialize do just save the state. The complication is what should the backend do when Atom front-end closes the WebSockets connection: Currently, the backend removes the session (process), unless the detach flag is set. I need to distinguish two kinds of closing:

  • If the connection is automatically closed because the DOM tree is being re-arranged, we need to preserve the session so it can be re-connected when the iframe is re-inserted into the tree. This case is a detach followed by an attach

  • If the correct is closed because the user clicked the close button on the pane then we want the session to be closed. (Perhaps shift-click should do detach.) The destroy method is called in this case (and not the previous case). The problem is the destroy method appears to be called after the unload event in the iframe window.

What would work is if could capture the button-click close event before the view item is removed. Then I could postMessage to the iframe window, which could then send a message (using the WebSockets connection) to the backed that the session should be closed.

Another solution may be for the destroy call to send a message directly to the server. That has its own complications as there is no direction communication link between the Atom view and the server. Using an XmlHttpRequest could probably be made to work.


#5

You can have a button that creates an event that indicates to your package that the user intends to close it (you should probably have this bound to esc as well). attach and detach should be associated with the lifecycle of the component, while the lifecycle of the session is controlled separately. If you have a server call to make, you can do that when the session ends.


#6

I don’t want to create a new button when there is a perfectly good button in the pane title bar, and which people will expect to close the terminal, and hence the associated process. (That’s what I mean by “session”.)


#7

Okay, I understand you now. I believe you can export a destroy() method that will be called when the pane item is closed for good.


#8

Yes, that seems to be the case: destroy is called when the pane is closed for good. The complication is that this is done after the window unload event, which makes it mor compiacted. It woule be easier if I could catch close event before the window is unloaded.


#9

I don’t know of a way to do that.


#10

atom-domterm seems to be working ok now. What I did was move the WebSocket connction out of the <iframe> and into the View item. Thus the WebSocket connection is kept open as the as the View persists, even if it dragged or otherwise removed/inserted. The DomTermView destroy method closes the WebSocket which (normally) closes the pty and user process. There are some complications to support detaching from a session so it can be re-attached to.