Mohammad DAMT wrote: >> > fcgi_manager_step returns immediately if there is a response from >> > fcgi server which has not being picked up by handler. then >> > handler would reset the buffer after pick the data and return it >> > to the main thread. >> >> Well, my original idea was: If the manager get something from the >> FastCGI server, it will process it, always. As long as it has a >> pointer to each connection which is currently using it and >> therefore waiting for some information, it will copy the >> information into its buffer. > > Is it safe to write directly to conn->buffer and > conn->header_buffer? But tried that but got no output to the > client.
It should not happen anything if you use conn->buffer. About conn->header_buffer, it is a different history. I wouldn't use it directly from a handler, it would be really messy. > Let's see this process: 0. handler -> 1. manager -> 2. handler > > at 0, handler A goes into, say, phase_add_headers then it calls manager > to read some data from fcgi > at 1, manager receives some data from fcgi, but the data is for another > thread of handler, say, for handler B. the manager then writes directly > to handler B's header buffer (or conn->buffer if the header has already > filled in in previous call). the manager then returns ret_eagain for > handler A because the data for A a is not available yet, and manager > should tell B that the data for it is ready. > at 2, handler then returns the return value it got from manager Well, as long as the handler 2 finds data in the buffer it will not call to the manager, it will simply consume it; so the manager doesn't need to tell B about the need data. > the tricky part is that the manager couldn't tell the handler directly > about the data being retrieved from fcgi server. is it ok if I use > handler_fastcgi_t type in the manager's pool instead of connection_t? > I could still pass a variable to be filled in by the manager if we are > going to use connection_t still. From the connection you can access the handler through ->handler, so it makes sense to use it, in this way we are sure we get everything. > another issue is that if the data for a handler is not ready yet, it > should try to get that again next time, so it's just returns > immediately from the manager. returning ret_again will cause some > CPU hog, especially if there are many threads running. is it ok to > have some timeout delay? Yeah, it might be a good idea. Have you seen the stuff in which is Diego Giagio working? By the moment I think we can just let it consume a few CPU cycles, and when Diego finish his patch we can check how to move the connection to sleep for sometime. > Yes, it was my fault to read from a finished cycle of fcgi protocol. > However, do we have some read timeout in cherokee_socket_read?, because > it waited forever there if there is no more data to be read. > > My current findings in many threads is this one: > Program received signal SIGPIPE, Broken pipe. > [Switching to Thread -1228862544 (LWP 26775)] > 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7f8ba18 in send () from /lib/tls/i686/cmov/libpthread.so.0 > #2 0xb7f7036b in cherokee_write (socket=0x8088a80, buf=0x812f420 "", buf_len=0, written=0xb6c10330) at socket.c:678 > #3 0xb7f707ea in cherokee_socket_write (socket=0x8088a80, buf=0xb7f7e2e4, written=0xb7f7e2e4) at socket.c:885 > #4 0xb7f47b8f in cherokee_connection_send (cnt=0x8088998) a connection.c:829 > #5 0xb7f4de9c in process_active_connections (thd=0x807fb00) at thread.c:955 > #6 0xb7f4e18a in cherokee_thread_step_MULTI_THREAD (thd=0x807fb00, dont_block=false) at thread.c:1489 > #7 0xb7f4e5e3 in thread_routine (data=0x807fb00) at thread.c:113 > #8 0xb7f86361 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 > #9 0xb7ed5bde in clone () from /lib/tls/i686/cmov/libc.so.6 > (gdb) run > > Somehow it lost the connection somewhere. Digging it. Actually, it is trying to send and empty packet. Take a look at buf_len in the frame number two. I'll check what is happening here, and I will let you know. :-) -- Greetings, alo. _______________________________________________ Cherokee mailing list [email protected] http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
