Hi Stephan, I had tried interprocess communication before and found it to be slow (12 sec vs 14ms). Somewhere in the docs, there was a mention that it has latency of 2ms. However, if you can point me to samples or provide other advise that make it as fast as osl::socket, I'd be happy to switch back to it.
Q1. I think you answered the question. I was hoping to keep single thread to manage multiple scalc but it seems like that would not be possible. Q2. Instead of using osl::AcceptorSocket and osl::ConnectorSocket, I tried to use #include <sys/socket.h> int socket = (PF_INET, SOCK_STREAM, 0); bind(socket, addr, addrlen); listen (socket, 5); This would allow me use scalable epoll but I had trouble compiling it. Q3. I would like to understand more about how these threads interact with connection::read/write. Is there an extra thread created for me per connection ? write would be called in my user thread. Is the data queued for writer thread ? read is called in my user thread. Is it listening on some UNO queue to which the dedicated reader thread queues data ? Or did you mean that I should create a dedicated thread per connection because read/write are blocking calls ? Thanks Neeraj -----Original Message----- From: Stephan Bergmann [mailto:sberg...@redhat.com] Sent: Monday, January 28, 2013 7:07 AM To: Rai, Neeraj [ICG-MKTS] Cc: 'libreoffice@lists.freedesktop.org' Subject: Re: [libreoffice-dev] - libreoffice 4.0 - waiting on multiple sockets On 01/26/2013 12:01 AM, Rai, Neeraj wrote: > I have an extension that is communicating with a a standalone shared lib > running via uno exe. I start a background thread in scalc and use > osl::socket (client/server) to pass data. In general, I would not recommend to create an own communication protocol there. As both processes are apparently able to speak UNO, you can use that for remote communication. On the uno exe side, you would need to invent some new UNO service that is running there and listening on a specific connection (you run the uno exe as "uno -s XXX -u uno:YYY;urp", where XXX is the name of your new service and YYY is the connection details, like "socket,host=localhost,port=1234"). The service could implement the rather generic com.sun.star.task.XJob interface, or you could even design one or more new UNO interface types that model your communication patterns more acurately. Let me dig for some useful examples if you want to go that route. > Q1. I need multiple scalc instances to connect to this uno exe. Is there > a way to achieve "select" or "epoll" functionality in osl::socket No. The way UNO uses this is to have a dedicated reader thread for each accepted (socket) connection. > Q2. I tried to use plain socket in uno shared lib but the scalc > extension did not respond. Then I tried compiling scalc extension using > plain sockets but had compilation issues. > It seems the bind/listen etc are renamed in sal layer. Not sure what you mean with the above. Stephan _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice