WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
208349
Introduce JSRemoteInspectorServerStart API for socket-based RWI.
https://bugs.webkit.org/show_bug.cgi?id=208349
Summary
Introduce JSRemoteInspectorServerStart API for socket-based RWI.
Ross Kirsling
Reported
2020-02-27 16:09:43 PST
Introduce JSRemoteInspectorServerStart APPI for socket-based RWI.
Attachments
Patch
(2.28 KB, patch)
2020-02-27 16:11 PST
,
Ross Kirsling
no flags
Details
Formatted Diff
Diff
Patch
(2.67 KB, patch)
2020-02-28 10:52 PST
,
Ross Kirsling
no flags
Details
Formatted Diff
Diff
Patch
(2.69 KB, patch)
2020-02-28 10:58 PST
,
Ross Kirsling
no flags
Details
Formatted Diff
Diff
Patch
(5.45 KB, patch)
2020-02-28 14:17 PST
,
Ross Kirsling
no flags
Details
Formatted Diff
Diff
Patch
(5.52 KB, patch)
2020-03-03 14:40 PST
,
Ross Kirsling
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Ross Kirsling
Comment 1
2020-02-27 16:11:43 PST
Created
attachment 391937
[details]
Patch
Ross Kirsling
Comment 2
2020-02-27 16:19:17 PST
This is needed for embedded applications making use of socket-based RWI. A couple of possible concerns: - I've guarded the declaration itself here based on Devin's recommendation, though it does seem a bit more typical to just no-op the implementation instead. - Our downstream version calls initializeThreading() too; I'd rather omit this as it feels like an orthogonal concern, but it can be added here if we absolutely need it.
Don Olmstead
Comment 3
2020-02-27 18:01:30 PST
Comment on
attachment 391937
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391937&action=review
> Source/JavaScriptCore/API/JSRemoteInspector.h:55 > +#if USE(INSPECTOR_SOCKET_SERVER) > +JS_EXPORT bool JSRemoteInspectorServerStart(uint16_t port) JSC_API_AVAILABLE(macos(JSC_MAC_TBA), ios(JSC_IOS_TBA)); > +#endif > +
I'm pretty sure having a USE in the API headers is a no go. These are all C headers. I'm going to guess there might need to be a JSRemoteInspectorSocket.h.
Ross Kirsling
Comment 4
2020-02-28 10:52:02 PST
Created
attachment 391996
[details]
Patch
Ross Kirsling
Comment 5
2020-02-28 10:58:01 PST
Created
attachment 391997
[details]
Patch
Joseph Pecoraro
Comment 6
2020-02-28 11:04:45 PST
Comment on
attachment 391997
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391997&action=review
Seems fine to me. It is weird exposing an API that does nothing on Apple ports but were they to implement `INSPECTOR_SOCKET_SERVER` then it would just work.
> Source/JavaScriptCore/API/JSRemoteInspector.cpp:92 > + auto& server = Inspector::RemoteInspectorServer::singleton(); > + return server.isRunning() || server.start(nullptr, port);
If the server is running it might be running on a different port. Should we return false in such a case, since this was requested to start with a particular port? Have you considered an option to start without a port, and let the OS pick a random available port? (Not necessarily important, just something to consider).
Devin Rousso
Comment 7
2020-02-28 11:05:27 PST
Comment on
attachment 391997
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391997&action=review
> Source/JavaScriptCore/API/JSRemoteInspector.h:53 > +JS_EXPORT bool JSRemoteInspectorServerStart(uint16_t port) JSC_API_AVAILABLE(macos(JSC_MAC_TBA), ios(JSC_IOS_TBA));
I'm not familiar with the "rules" about the JSC C API, but I'd think that we wouldn't want to expose a function that doesn't actually do anything. If this is done elsewhere (and the JSC folks are fine with it), then I guess it's fine. I'd really prefer if the function only existed when `USE(INSPECTOR_SOCKET_SERVER)` is guaranteed to be true.
Joseph Pecoraro
Comment 8
2020-02-28 11:06:21 PST
(In reply to Don Olmstead from
comment #3
)
> Comment on
attachment 391937
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=391937&action=review
> > > Source/JavaScriptCore/API/JSRemoteInspector.h:55 > > +#if USE(INSPECTOR_SOCKET_SERVER) > > +JS_EXPORT bool JSRemoteInspectorServerStart(uint16_t port) JSC_API_AVAILABLE(macos(JSC_MAC_TBA), ios(JSC_IOS_TBA)); > > +#endif > > + > > I'm pretty sure having a USE in the API headers is a no go.
Correct regarding having `USE` in an API header!
> These are all C headers. I'm going to guess there might need > to be a JSRemoteInspectorSocket.h.
This isn't a bad idea, I considered it as well. Then ports that don't want to expose this API/Symbol could just not include the header/implementation. I'm not sure if there is a common practice for that.
Don Olmstead
Comment 9
2020-02-28 11:08:58 PST
Comment on
attachment 391997
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391997&action=review
>> Source/JavaScriptCore/API/JSRemoteInspector.cpp:92 >> + return server.isRunning() || server.start(nullptr, port); > > If the server is running it might be running on a different port. Should we return false in such a case, since this was requested to start with a particular port? > > Have you considered an option to start without a port, and let the OS pick a random available port? (Not necessarily important, just something to consider).
I think address should probably be exposed as well on this API.
Don Olmstead
Comment 10
2020-02-28 11:17:48 PST
Comment on
attachment 391997
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391997&action=review
>> Source/JavaScriptCore/API/JSRemoteInspector.h:53 >> +JS_EXPORT bool JSRemoteInspectorServerStart(uint16_t port) JSC_API_AVAILABLE(macos(JSC_MAC_TBA), ios(JSC_IOS_TBA)); > > I'm not familiar with the "rules" about the JSC C API, but I'd think that we wouldn't want to expose a function that doesn't actually do anything. If this is done elsewhere (and the JSC folks are fine with it), then I guess it's fine. I'd really prefer if the function only existed when `USE(INSPECTOR_SOCKET_SERVER)` is guaranteed to be true.
I don't know what the practice is for it but if it was to go into a separate file then on the CMake side the header would need to be appended to JavaScriptCore_PUBLIC_FRAMEWORK_HEADERS on the CMake side. if (USE_INSPECTOR_SOCKER_SERVER) list(APPEND JavaScriptCore_PUBLIC_FRAMEWORK_HEADERS API/JSRemoteInspectorServer.h endif ()
Basuke Suzuki
Comment 11
2020-02-28 11:18:11 PST
Comment on
attachment 391997
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=391997&action=review
>> Source/JavaScriptCore/API/JSRemoteInspector.h:53 >> +JS_EXPORT bool JSRemoteInspectorServerStart(uint16_t port) JSC_API_AVAILABLE(macos(JSC_MAC_TBA), ios(JSC_IOS_TBA)); > > I'm not familiar with the "rules" about the JSC C API, but I'd think that we wouldn't want to expose a function that doesn't actually do anything. If this is done elsewhere (and the JSC folks are fine with it), then I guess it's fine. I'd really prefer if the function only existed when `USE(INSPECTOR_SOCKET_SERVER)` is guaranteed to be true.
We cannot use USE(INSPECTOR_SOCKET_SERVER) here in C API headers. All we can do is using standard definition check for possible platforms to enable this. i.e) #if defined(WIN32) || defined(_WIN32) || defined(__SCE__)
Ross Kirsling
Comment 12
2020-02-28 14:17:40 PST
Created
attachment 392020
[details]
Patch
Ross Kirsling
Comment 13
2020-02-28 14:19:47 PST
Comment on
attachment 392020
[details]
Patch Here's a version that addresses most of the voiced concerns. Not going to land this yet though, as Basuke would like to adjust the return type of RemoteInspectorServer::start in
bug 208391
first.
Ross Kirsling
Comment 14
2020-03-03 14:40:52 PST
Created
attachment 392335
[details]
Patch
WebKit Commit Bot
Comment 15
2020-03-03 15:47:28 PST
Comment on
attachment 392335
[details]
Patch Clearing flags on attachment: 392335 Committed
r257809
: <
https://trac.webkit.org/changeset/257809
>
WebKit Commit Bot
Comment 16
2020-03-03 15:47:31 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 17
2020-03-03 15:48:17 PST
<
rdar://problem/60017043
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug