Bug 179538 – webkitpy: Separate AsyncProcess from ServerProcess

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Tools / Tests

[Jonathan Bedard]

Requiring ServerProcess to be passed a port object makes this class difficult to use outside of running layout tests.

[Radar WebKit Bug Importer]

<rdar://problem/35472080>

[Jonathan Bedard]

Created attachment 326608 [details]
Patch

[Jonathan Bedard]

This change will happen in 3 different patches.

The first (posted now) is the meat of the change, the ServerProcess will no longer use any port bits.

The second will allow the ServerProcess to be constructed with either a port or a host.

The third will removed the support for constructing a ServerProcess with a port.

We need to distinguish between the 2nd and 3rd patch because syncing up apple_additions and webkitpy changes is quite difficult.

[Jonathan Bedard]

Created attachment 326612 [details]
Patch

[Jonathan Bedard]

Created attachment 326614 [details]
Patch

[Jonathan Bedard]

Comment on attachment 326614 [details]
Patch

I discussed this with Dan Bates on 11/14.

He is of the opinion that the ServerProcess should only be used for layout tests.  As I've looked into how we use the server process, I think there is a better way forward.

Throughout webkitpy, we have a number of places we could use an asynchronous shell command.  For example, Simon mentioned to me a few days ago that when we run sample after a layout test has hung, we block until the command has returned.  There is no reason we need to block.

To solve this problem, I think we should split the server process into an asynchronous subprocess call and the server process, which would use the asynchronous subprocess call along with a few lifetime management tools and callbacks.

[Jonathan Bedard]

Created attachment 327132 [details]
Patch

[Jonathan Bedard]

(In reply to Jonathan Bedard from comment #7)
> Created attachment 327132 [details]
> Patch

This patch needs to be polished and have unit tests, sending it through EWS to check that it doesn't break Windows.

[Jonathan Bedard]

Created attachment 327223 [details]
Patch

[Jonathan Bedard]

Created attachment 327694 [details]
Patch

[Jonathan Bedard]

This is the wrong way to do this.

The POpen object achieves nearly the same thing, and since we already embed a popen call in the executive, this code needlessly complicates the ServerProcess.