IPC implementation help in haiku's webkit port

# Rajagopalan Gangadharan (4 days ago)

Hello Everybody,

I stumbled upon a problem in an attempt to port webkit to haiku. Before everything I would like to take few moments to explain about state of the port.

1) We have a well maintained WebKitLegacy port on haiku. 2) Now in the process of porting latest webkit to haiku currently at fixing IPC. We didnt want to use BSD sockets and would like to use Native messaging framework [BMessage : www.haiku-os.org/docs/api/classBMessage.html ] because our native application waits for BMessage in its main thread as a result we cant wait for both sockets and BMessage on same thread. Also we would like to maintain the haiku ecosystem :) .

3) We need process id of the intended process we would like to connect to send data [BMessenger: www.haiku-os.org/docs/api/classBMessenger.html ] So instead of exchanging socket id's we would just exchange pid's

4) We were able to successfully deliver and process the messages. Currently we were able to proceed until creating a connection between network process and webprocess(NetworkConnectionToWebProcess).

Now where we are stuck is that After creating a connection between network process and webprocess we would have to reply back to webprocess about the connection info( pid of network process in our case ). I see the reply is an alias of DelayedReply(CompletionHandler<Attachment&>) according to the

derived sources. Unfortunately the webprocess is indefinitely waiting for reply from webprocessproxy for which we are unable to "reply" .

Could anyone point me where I would have went wrong or what could be done to fix this and any better ways for implementing this.

Please check the source references for more info: NetworkProcessProxy: [ RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp#L150 ]

NetworkProcess [ RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/NetworkProcess/haiku/NetworkProcessHaiku.cpp#L98 ]

ConnectionHaiku : [ RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Source/WebKit/Platform/IPC/haiku/ConnectionHaiku.cpp ]

Attachment : [ RAJAGOPALAN-GANGADHARAN/webkit/blob/ipc-iteration2/Source/WebKit/Platform/IPC/haiku/AttachmentHaiku.cpp ] I believe these places are currently in focus For further reference please check [ RAJAGOPALAN-GANGADHARAN/webkit/tree/ipc-iteration2]

Thank you

Contact us to advertise here
# Alex Christensen (3 days ago)

It sounds like your design requires work on the main thread to create a connection to another process which is causing a deadlock when the main thread is waiting for another reply. If I were working on this I would compare with an existing implementation to see what process and thread each step is running on.

# Chris Dumez (3 days ago)

Alex is likely right that you are ending up with some kind of IPC deadlock since the IPC is synchronous.

But also,

On May 27, 2019, at 11:49 PM, Rajagopalan Gangadharan <g.raju2000 at gmail.com> wrote:

Please check the source references for more info: NetworkProcessProxy: [ RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp#L150, RAJAGOPALAN-GANGADHARAN/webkit/blob/6bf81d79669be06b4efd9d8ced4139cbe07216b2/Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp#L150]

You’re passing 0 instead of the webPID with the IPC here.

# Rajagopalan Gangadharan (2 days ago)

Thank you for the response guys. It was really wise advice we indeed realized that we should not rely on run loop for communicating with other process. So we have come with a solution to bypass the mainloop. :)

Want more features?

Request early access to our private beta of readable email premium.