Right, 8 bytes, not 16, I've misread https://github.com/real-logic/agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/ringbuffer/RecordDescriptor.java. Thanks for note.
On Fri, 30 Mar 2018, 19:16 Martin Thompson, <[email protected]> wrote: > Aeron IPC is more functional than a plain queue but I get your point that > it is not a drop in replacement. > > The ring buffers are typical queue based semantics and use an 8 byte > header in Agrona and Aeron. 4 bytes for message length and 4 bytes for > message type to give some flexibility. Fixed format messages can optimise > well but have limited applicability. > > On Friday, 30 March 2018 16:36:09 UTC+1, Roman Leventov wrote: >> >> Martin, thanks a lot! >> >> I thought about Aeron IPC, but as far as I understand it maps to the >> queue model only when there is a single producer and a single consumer. >> Also it felt a little too heavyweight for small fixed-sized messages. >> Generally Aeron's Data frames have 32-byte headers. RingBuffers have only >> 16-byte headers, and it looks like it could be harmlessly reduced down to 8 >> or even 0 for e. g. fixed format 32-byte messages. >> >> There are implementations of FIFO ring buffers for Java and C++ used in >>> Aeron for doing exactly this. >>> >>> >>> https://github.com/real-logic/aeron/tree/master/aeron-client/src/main/cpp/concurrent >>> >>> >>> https://github.com/real-logic/agrona/tree/master/agrona/src/main/java/org/agrona/concurrent >>> >>> You could also use Aeron IPC. >>> >>> On Friday, 30 March 2018 09:55:23 UTC+1, Roman Leventov wrote: >>>> >>>> I think about the possibility of building an asynchronous application >>>> with back pressure where some upstream operators are in Java and some >>>> downstream ones are in C++. For this purpose, some queues would be needed >>>> to pass the data between Java and C++ layers. It seems that porting >>>> JCTools's bounded array queues to off-heap should be doable, but I couldn't >>>> find existing prototypes or discussions of such thing so maybe I overlook >>>> some inherent complications with this idea. >>>> >>>> Did anybody think about something like this or has implemented in >>>> proprietary systems? >>>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
