On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda <ken...@google.com> wrote:

> Note that the protocol buffer parser is not asynchronous.  That means you
> either need to feed it an entire message at once, or it will need to block
> waiting for mode data to arrive on


s/mode/more


> the input stream.  So if you want to do something asynchronous, you best
> bet is probably to do your own buffering until you have received an entire
> message, then pass the bytes off to the protobuf parser.  You probably won't
> need to implement any custom ZeroCopyStreams for that.
>
>
> On Thu, Jun 18, 2009 at 8:30 PM, brodie <brofi...@gmail.com> wrote:
>
>>
>> Hi all,
>>
>> Has anyone done any work to create a stream implementation for async
>> use? In particular, Windows async sockets or async named pipes?
>>
>> I'm planning to implement PB as the messaging layer on top of a
>> Windows sockets transport layer (therefore using HANDLE instead of a
>> file descripter). We may additionally make this layer swappable with
>> named pipes (also a HANDLE). Transport in both cases will be done
>> async. On Linux/OSX we will just use async sockets.
>>
>> It would be nice if someone has already done some work in this area
>> that I can leverage/build on. Any pointers?
>>
>> Regards,
>> Brodie
>>
>> >>
>>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to