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