Hello! On Wed, Mar 06, 2013 at 12:01:44AM +0100, alexander_koch_log wrote:
> On 02/10/2013 12:25 AM, Maxim Dounin wrote: > >Hello! > > > >On Sat, Feb 09, 2013 at 04:41:54PM +0100, alexander_koch_log wrote: > > > >>It is not clear to me how to avoid blocking the nginx reactor loop > >>when creating an nginx module which should perform some long I/O > >>operations and return the response to the client. Or is this > >>handled internally by Nginx? > >Correct aproach is to avoid blocking for a long time, and use > >non-blocking I/O and event-based notification instead. > > > >What exactly should (and can) be done depends on the exact case. > >E.g. to work with sockets there are lots of various functions > >available to simplify things. Working with files without blocking > >is harder and not always possible, but a common case is handled by > >nginx - to send some large file you just have to open the file and > >ask nginx to send an in-file buffer. > > > > When sending an in-file buffer, is it still possible to have the > read stop when a special byte char is read like \xFF even though the > provided bytes to read are larger? As e.g. with sendfile used file's data is never available in user memory, the answer is no. > One way would be to read to the buffer then truncate the memory, > then send the buffer? Or is there an efficient way? What you are trying to do is probably beter handled by a filter module. You may ask nginx to read a file into memory buffers (output_buffers), and then inspect/modify all data passed though you filter. -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
