[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [patch] Re: Can modules block on socket writes? (fwd)



On Tuesday 13 March 2001 20:34 you wrote:
[...]
>
> please check out the -S6 patch i've just uploaded, plus the new 2.0.19
> tarball. I've implemented TUX_ACTION_SEND_BUFFER, which is an asynchron,
> event-based send-buffer function for TUX modules. The tarball includes
> demo5.c which shows how to use it:
>
[...]
>
> requests are automatically scheduled away by TUX if there is not enough
> write space, and req->event should be used to catch the completion event.
> This can be used to malloc()/free() temporary userspace buffers as well.
>
> TUX_ACTION_SEND_BUFFER is from now on the preferred method of sending data
> to the client. write() to the socket can still be used, but only from
> helper threads, to not block the whole TUX process with a slow client.
>
> does this mechanism solve your problem?
>

First: as you might have realized I have fallen off the list somehow, I don't 
know if it's a problem with the list or with my service provider, just 
checking this.

Anyway, the TUX_ACTION_SEND_BUFFER helps a lot, yes. I just don't understand 
how the module realizes that it is scheduled away and how it should finish 
the buffer send.

Maybe I understood you wrong, but didn't you mean that in case of not enough 
write space (socket buffer space or main memory?) the module has to reissue a 
TUX_ACTION_SEND_BUFFER with the rest of the buffer. How does the module know 
that this case happened and how much has been transferred?

My initial question about the blocking of socket writes came up, because I 
want to deliver dynamic pages in an efficient way. Since you have static and 
dynamic parts in dynamic pages I prepared the static parts into files and 
wrote the dynamic parts into the socket. 

I made a comparison between sending parts of a html page completely via 
GET/SEND_OBJECT and completely via write(req->sock...) . The comparison 
showed that if there are many (1024) splitters of my html page the socket 
approach is much faster. Okay it is quite uncommon to have so many parts to 
assemble, but if you have many requests for fewer splitters then the same 
problem will arise.

So I decided not to prepare static parts of a page into files but to write 
everything into the socket. Now I will put everything into a buffer and use 
SEND_BUFFER.

Bye, Marcus

-- 
Marcus Gruendler
eMail: runner@tamalin.de
WWW: http://www.tamalin.de/runner/index.html





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []