From attila.lendvai at gmail.com Fri Nov 6 20:30:06 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Fri, 6 Nov 2009 20:30:06 +0000 Subject: [iolib-devel] c10k HTTP server with iolib In-Reply-To: References: Message-ID: > Here is a possible architecture for a server that can handle tons of > connections at once: this is all fine, but the interesting question comes when you consider how to switch between the threads. what you need is essentially green-threads (much cheaper compared to OS threads): http://en.wikipedia.org/wiki/Green_threads the naive solution is to implement the inversion of control by hand, having hand-written state machines, etc all around. this makes the code uglier, and through that helps for bugs creeping in. another solution is to implement green threads. and yet another solution is to use a currently available call/cc implementation (cl-cont or hu.dwim.delico). delimited continuations provide more than green threads, and therefore mean more overhead, but the difference shouldn't be big. unfortunately for now delico only provides interpreted continuations (slow), and cl-cont had quite a few issues when i tried it. but using cl-cont i've made a proof of concept implementation. the idea in short: keep a connection data structure for each connection set sockets to non-blocking provide call/cc versions of socket (gray-stream) reading primitives which when detect that the socket is dry or flooded then store the current continuation in the connection structure and mark what event we are waiting for and then continue (using call/cc primitives) connections based on what the event handler layer tells us. please note that call/cc is only needed on the code that reads the request. once it's parsed, the rest of the handler code can be plain CL up to the point when we start writing the response. if you need some stream processing that does not buffer the response before sending, then you need to keep all the handler code inside the delimited continuation borders. it's somewhere on my TODO to make hu.dwim.wui work based on that experiment. currently the wui codebase can process some 3-4 k requests per sec on my 2.4 GHz core2 laptop, which is good enough for me, especially that i didn't pay too much attention to performance. but for now it can only cope with about 50 parallel requests a second, because workers are not multiplexed. if there are many users with slow network connections then it can be an issue... the proof of concept code is lying somewhere in an iolib branch here, but it's most probably badly bitrotten. it's about a year old now and iolib went much ahead. -- attila From marsijanin at gmail.com Sun Nov 8 18:09:24 2009 From: marsijanin at gmail.com (marsijanin at gmail.com) Date: Sun, 08 Nov 2009 21:09:24 +0300 Subject: [iolib-devel] Extension for serial devices support. Message-ID: <87skco6g8b.fsf@fobos.mars> I run it under sbcl, clisp and ccl under 32 bit archlinux. I found mercurial command syntax more simple than git, so project is hosted at bitbucket.org: http://bitbucket.org/marsijanin/iolib.termios/ Hope my little extension will be useful. Best, Nikolay V. Razbegaev P.S. I also have some plans for parallel interface (by making libieee1284 bindings) in the future. From attila.lendvai at gmail.com Sun Nov 15 23:12:24 2009 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 16 Nov 2009 00:12:24 +0100 Subject: [iolib-devel] poll error leaking from write-sequence Message-ID: Stelian, i think it's not against the rules to signal other exceptions than stream-error from sequence calls, but it's causing me more and more headaches. the situation: i want to log errors happening while our web server is serving requests, but i want to keep the error log noise-free. network related errors are considered noise, so i have a function that decides whether the error is coming from the network stream connected to the client: (def function is-error-from-client-stream? (error client-stream) (bind ((client-stream-fd (iolib:fd-of client-stream))) (or (and (typep error 'stream-error) (eq (stream-error-stream error) client-stream)) ;; TODO the rest is fragile and easily breaks when iolib changes behavior (and client-stream-fd (and (typep error 'iolib:socket-error) (eql client-stream-fd (isys:handle-of error))) ;; TODO signalling non stream-error conditions might be an iolib bug (and (typep error 'iolib.multiplex:poll-error) (eql client-stream-fd (iolib.multiplex:poll-error-fd error))))))) this function keeps getting longer, but the bigger issue is that it highly depends on iolib's internal implementation. is there any chance to add it to iolib's contracts that it only signals stream-error from stream calls like write-sequence? it could chain the original condition not to lose information... or do you have some other suggestions? -- attila ps: the new error that started to show up after i temporarily made the client sockets blocking until we fully implement connection multiplexing (the error is most probably that the connection was reset, client cancelled the download): Error caught while polling file descriptor 9: Unknown error *** Backtrace: 6: (HANDLE-TOPLEVEL-ERROR # #) 7: ((FLET HU.DWIM.WUI::HANDLE-REQUEST-ERROR) #) 8: ((LABELS HU.DWIM.UTIL::HANDLE-LEVEL-1-ERROR) #) 9: (SIGNAL #) [:EXTERNAL] 10: (ERROR POLL-ERROR) [:EXTERNAL] 11: (IOLIB.MULTIPLEX::PROCESS-POLL-REVENTS 24 9) 12: (WAIT-UNTIL-FD-READY 9 :OUTPUT NIL T) 13: (IOLIB.STREAMS::%WRITE-OCTETS-FROM-FOREIGN-MEMORY IOLIB.SOCKETS::SOCKET-WRITE-FN 9 #.(SB-SYS:INT-SAP #X100B7C7010) 8192) 14: (IOLIB.STREAMS::%WRITE-SIMPLE-ARRAY-UB8 # #(173 24 188 120 227 48 246 217 166 31 219 246 223 156 15: (WRITE-SEQUENCE #(173 24 188 120 227 48 246 217 166 31 219 246 223 156 67 143 56 133 143 102 199 237 58 116 214 169 16 138 87 110 26 198 192 45 54 96 16: ((LABELS HU.DWIM.WUI::WITH-CONTENT-SERVING-LOGIC-BODY) ((\"Content-Length\" . \"1957376\") (\"Content-Type\" . \"application/msword\") (\"Date\" . \" 17: (HU.DWIM.WUI::SERVE-FILE #P\"/var/opt/darcs/ebr42-hydrogen/documents/ebr42 - Felhaszn?l?i k?zik?nyv ?nkorm?nyzatoknak.doc\") [:EXTERNAL] From vsedach at gmail.com Mon Nov 16 08:15:23 2009 From: vsedach at gmail.com (Vladimir Sedach) Date: Mon, 16 Nov 2009 03:15:23 -0500 Subject: [iolib-devel] Patches to make multiplexer use easier Message-ID: Hello, Here are some patches that make it easier to just use the multiplexer object without having to go through the provided event loop/timer machinery. This is done in three steps: make the monitor/harvest etc. methods on multiplexer accept just file descriptors as well as FD-ENTRYs (note that I've only done that for epoll in this set of patches, others to come!), export the handler methods, and add an optional flags parameter to the MONITOR-FD method (really useful for epoll, the other backends I'm not sure about). Let me know what you think. I'd like to get these patches (or at least the equivalent functionality of being able to use the multiplexer without having to make FD-ENTRYs) into IOlib as I'm about to release some software that uses it. Thanks, Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-writev-system-call.patch Type: text/x-diff Size: 1339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Made-return-value-of-HARVEST-EVENTS-consistent-acros.patch Type: text/x-diff Size: 3913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Exported-the-monitor-update-harvest-etc.-operations-.patch Type: text/x-diff Size: 825 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Added-a-flags-parameter-to-MONITOR-FD-multiplexer-me.patch Type: text/x-diff Size: 3640 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Made-epoll-multiplexer-take-a-simple-integer-file-de.patch Type: text/x-diff Size: 5630 bytes Desc: not available URL: From vsedach at gmail.com Mon Nov 16 20:11:56 2009 From: vsedach at gmail.com (Vladimir Sedach) Date: Mon, 16 Nov 2009 15:11:56 -0500 Subject: [iolib-devel] Patches to make multiplexer use easier In-Reply-To: References: Message-ID: Here's a corrected patch for 0005 that supersedes the one in my previous message. Vladimir 2009/11/16 Vladimir Sedach : > Hello, > > Here are some patches that make it easier to just use the multiplexer > object without having to go through the provided event loop/timer > machinery. This is done in three steps: make the monitor/harvest etc. > methods on multiplexer accept just file descriptors as well as > FD-ENTRYs (note that I've only done that for epoll in this set of > patches, others to come!), export the handler methods, and add an > optional flags parameter to the MONITOR-FD method (really useful for > epoll, the other backends I'm not sure about). > > Let me know what you think. I'd like to get these patches (or at least > the equivalent functionality of being able to use the multiplexer > without having to make FD-ENTRYs) into IOlib as I'm about to release > some software that uses it. > > Thanks, > Vladimir > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Made-epoll-multiplexer-take-a-simple-integer-file-de.patch Type: text/x-diff Size: 5632 bytes Desc: not available URL: From sionescu at cddr.org Thu Nov 19 17:19:08 2009 From: sionescu at cddr.org (Stelian Ionescu) Date: Thu, 19 Nov 2009 18:19:08 +0100 Subject: [iolib-devel] poll error leaking from write-sequence In-Reply-To: References: Message-ID: <1258651148.8519.19.camel@blackhole.cddr.org> On Mon, 2009-11-16 at 00:12 +0100, Attila Lendvai wrote: > Stelian, i think it's not against the rules to signal other exceptions > than stream-error from sequence calls, but it's causing me more and > more headaches. > > the situation: i want to log errors happening while our web server is > serving requests, but i want to keep the error log noise-free. network > related errors are considered noise, so i have a function that decides > whether the error is coming from the network stream connected to the > client: > > (def function is-error-from-client-stream? (error client-stream) > (bind ((client-stream-fd (iolib:fd-of client-stream))) > (or (and (typep error 'stream-error) > (eq (stream-error-stream error) client-stream)) > ;; TODO the rest is fragile and easily breaks when iolib > changes behavior > (and client-stream-fd > (and (typep error 'iolib:socket-error) > (eql client-stream-fd (isys:handle-of error))) > ;; TODO signalling non stream-error conditions might be > an iolib bug > (and (typep error 'iolib.multiplex:poll-error) > (eql client-stream-fd (iolib.multiplex:poll-error-fd > error))))))) > > this function keeps getting longer, but the bigger issue is that it > highly depends on iolib's internal implementation. > > is there any chance to add it to iolib's contracts that it only > signals stream-error from stream calls like write-sequence? it could > chain the original condition not to lose information... > > or do you have some other suggestions? I'd rather not do chaining because that would disallow the use of restarts. I think it would be better to make sure that only two error types can come out of a stream operation: CL:STREAM-ERRORs signaled by the Gray stream layer, and ISYS:SYSCALL-ERRORs signaled by low-level code. I've logged it as https://bugs.launchpad.net/iolib/+bug/485392 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sionescu at cddr.org Fri Nov 20 16:18:45 2009 From: sionescu at cddr.org (Stelian Ionescu) Date: Fri, 20 Nov 2009 17:18:45 +0100 Subject: [iolib-devel] Extension for serial devices support. In-Reply-To: <87skco6g8b.fsf@fobos.mars> References: <87skco6g8b.fsf@fobos.mars> Message-ID: <1258733925.4239.5.camel@blackhole.cddr.org> On Sun, 2009-11-08 at 21:09 +0300, marsijanin at gmail.com wrote: > I run it under sbcl, clisp and ccl under 32 bit archlinux. I found > mercurial command syntax more simple than git, so project is hosted at > bitbucket.org: http://bitbucket.org/marsijanin/iolib.termios/ > > Hope my little extension will be useful. > > Best, > > Nikolay V. Razbegaev > > P.S. I also have some plans for parallel interface (by making libieee1284 > bindings) in the future. Thanks for providing this. Is it ok if I incorporate it into IOLib or do you prefer to develop it outside ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From vsedach at gmail.com Sat Nov 21 11:04:55 2009 From: vsedach at gmail.com (Vladimir Sedach) Date: Sat, 21 Nov 2009 06:04:55 -0500 Subject: [iolib-devel] Patches to make multiplexer use easier In-Reply-To: References: Message-ID: Here's a patch that finishes adding the interface to the other multiplexer backends. Now it should be possible to use all of them for simple readiness notification on a set of integer fds. For example use, take a look at: http://github.com/vsedach/HTTP-DOHC Vladimir 2009/11/16 Vladimir Sedach : > Here's a corrected patch for 0005 that supersedes the one in my > previous message. > > Vladimir > > 2009/11/16 Vladimir Sedach : >> Hello, >> >> Here are some patches that make it easier to just use the multiplexer >> object without having to go through the provided event loop/timer >> machinery. This is done in three steps: make the monitor/harvest etc. >> methods on multiplexer accept just file descriptors as well as >> FD-ENTRYs (note that I've only done that for epoll in this set of >> patches, others to come!), export the handler methods, and add an >> optional flags parameter to the MONITOR-FD method (really useful for >> epoll, the other backends I'm not sure about). >> >> Let me know what you think. I'd like to get these patches (or at least >> the equivalent functionality of being able to use the multiplexer >> without having to make FD-ENTRYs) into IOlib as I'm about to release >> some software that uses it. >> >> Thanks, >> Vladimir >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Finished-implemeting-public-FD-descriptor-only-inter.patch Type: text/x-diff Size: 17672 bytes Desc: not available URL: From marsijanin at gmail.com Sun Nov 22 13:41:38 2009 From: marsijanin at gmail.com (marsijanin at gmail.com) Date: Sun, 22 Nov 2009 16:41:38 +0300 Subject: [iolib-devel] Extension for serial devices support. In-Reply-To: <1258733925.4239.5.camel@blackhole.cddr.org> (Stelian Ionescu's message of "Fri, 20 Nov 2009 17:18:45 +0100") References: <87skco6g8b.fsf@fobos.mars> <1258733925.4239.5.camel@blackhole.cddr.org> Message-ID: <87bpiuoewd.fsf@fobos.mars> Stelian Ionescu writes: > On Sun, 2009-11-08 at 21:09 +0300, marsijanin at gmail.com wrote: >> I run it under sbcl, clisp and ccl under 32 bit archlinux. I found >> mercurial command syntax more simple than git, so project is hosted at >> bitbucket.org: http://bitbucket.org/marsijanin/iolib.termios/ >> >> Hope my little extension will be useful. >> >> Best, >> >> Nikolay V. Razbegaev >> >> P.S. I also have some plans for parallel interface (by making libieee1284 >> bindings) in the future. > > Thanks for providing this. > > Is it ok if I incorporate it into IOLib or do you prefer to develop it > outside ? Hi, Stelian. I guess that incorporation will be best solution. IOLib.termios is my first experience in code sharing and cffi coding. I currently haven't much time to support this my little IOLib extension because of deadline at my work, but I hope, that it should not be a big problem in the future. Besides, I believe that it will be a chance to learn more about git for me. Anyway there are still two questions about incorporation: how exactly you are going to incorporate and to collaborate? Will the incorporation be just coping files and calling "git add" or there is a way to import mercurial project into git? I don't suppose, that history of my little part is really important -- just asking. And after that -- how should we collaborate? Should I just send patches into mailing list or will you give me write access to the project repository? I'm planing to sit down and make normal condition system for IOLib.termios when I have time for it. I also suppose that termios constants should be defined via constantenum and stty syntax should be changed in order to accept keywords arguments. I also started to write the extension for parallel interfaces (I called it IOLib.ieee1284). I wrote wrappers low level function in libieee1284 and wrote some hi level wrappers for reading parallel port lines as bit vectors in raw mode. I'm glad, that you think that my little part was useful. Best, Nikolay V. Razbegaev