On Thu, Jan 28, 2016 at 12:12 AM, Charles Remes <[email protected]> wrote: > >> On Jan 27, 2016, at 16:42, Ben Noordhuis <[email protected]> wrote: >> >> On Wed, Jan 27, 2016 at 11:15 PM, Charles Remes <[email protected]> wrote: >>> I’m a libuv newbie, so be gentle. I was looking through the allowed >>> operations for a File and noticed that there is no equivalent of >>> `uv_fs_lseek` in the library. I did a search on the term ‘seek’ on the docs >>> and only a single hit came back for the UV_ESPIPE error (invalid seek). >>> >>> So, how is this accomplished? Do I need to retrieve the FD and use the work >>> queue to perform a seek directly? >>> >>> Thanks for any help or pointers. >> >> The short answer is "you don't" - lseek() is unpredictable with >> concurrent readers or writers. The libuv way is to use positional >> reads and writes (the offset argument to uv_fs_read() and >> uv_fs_write().) > > Okay, I see that parameter now. Thanks for the pointer. That makes a lot of > sense in the context of concurrent readers/writers. > > But of course, it also raises a new question for me. If I fire off two write > calls back-to-back, would the offset of the second write need to be including > the size of the data written in the first write? Presumably you now need to > be really careful about keeping track of the file size (assuming we are > appending).
That's right, the second offset should be first_offset + first_length. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
