On 01/28/2013 04:04 PM, Rai, Neeraj wrote:
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.
"Generic" UNO IPC with all its bells and whistles easily introduces more
overhead than any solution tailored to one specific use-case, but "12
sec vs 14ms" surely sounds broken. Hard to tell what's gone wrong there
from a high-level perspective.
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.
There should be no general reason this should not work. (It would mean
the code is platform-specific, of course.)
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 ?
Reading/writing are blocking operations at the OSL socket level.
Stephan
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.