Fantastic, thanks Marc! I had not realized that I could use libev for the NAS reads just like I am using it for the socket reads. It will be perfect. And I've done this type of incremental buffer processing before, so I think I will do it myself.
Thanks again, I really appreciate the help. Aaron On Sun, May 22, 2011 at 8:13 AM, Marc Lehmann <[email protected]> wrote: > On Sat, May 21, 2011 at 10:25:45PM -0400, Aaron Boxer <[email protected]> > wrote: >> I found sample code that allows me to read and write from the socket >> using libev I/O events. >> But, I am not sure how to handle the read from NAS and processing. >> This could take some time. >> And I don't want to block the server while this is happening. > > In general, what you do is enable non-blocking I/O, and then you have to > implement buffering, i.e. when you know there is readable data, you try to > read a good sized amount (e.g. 4096) into some buffer and then you try to > parse out your requests, keeping partial requests in the buffer for the > next read. > > If you are experienced doing that it will not pose any problems, if not, > it can be a time-consuming task to get the details right the first time, and > naked libev doesn't help with any of the buffering. > > It is, however, more flexible, and instructive, an you cna cut corners you > might not be abel to cut with a generic library. > > Also, for writing, you need to do the same, as the socket wil only accept > so and so much data per time. > > Recently somebody posted details about a networking library on top of > libev (https://github.com/coolaj86/libevn - haven't looked at it in > detail, presumably it handles buffering for you). There is also libevent > (which I wouldn't recommend in itself), which is weird, but it presumably > has quite powerful and full-featured buffer handling for sockets. > >> Should this be done in another thread, and have the thread send the >> image data back to the client? > > If you have only a few clients at a time, and locking is easy, then threads > might be simpler. If you have many clients, you probably want to use > something like libev. If you have even more and locking is easy, you might > want to have one thread per cpu core using libev, and if you have even more > clients you need to run with many processes, potentially on different hosts. > > All depends on how much effort you want (or have to) go. > >> I was planning on using a thread pool. But, perhaps libev can support >> a processing step without >> blocking? > > Yes, libev is quite ideally suited for this problem as it efficiently gives > you events on when data is ready to be read or written. > > It does only work on non-blocking handles though, files would always > be ready (because the data is there), so if you want to do files in an > event-based way, you could look at libeio (which implements a thread pool > for I/O). > > -- > The choice of a Deliantra, the free code+content MORPG > -----==- _GNU_ http://www.deliantra.net > ----==-- _ generation > ---==---(_)__ __ ____ __ Marc Lehmann > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\ > _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
