Hi everyone, my company is currently developing a specific framework on SuperH architectures (sh4) and I would like to investigate whether we could use mongrel2 as part of it since it's highly client/server based and needs good real-time performance, of course. So I'd like to know: - does any of you have an idea of the amount of work to get mongrel2 working on SuperH? What are the architecture specific parts of it? I suppose they are coupled to ZeroMQ. - if that seems to much work, does any of you know whether ZeroMQ alone is easy to port (or already ported) to SuperH architecture? A few missing details: I'm running a GNU/Linux with glibc (we don't plan on using uclibc) on the sh4 so it's a pretty standard configuration. Thanks for your feedbacks, Lionel
Hi Lionel, Mongrel2 relies on a cooperative multitasking library that would have to be ported to SH; the CPU specific stuff is just basic context save/restore, so it shouldn't be too hard. The mongrel libtask is based off of Russ Cox's libtask, which has been ported to mips and power as well as x86/x86_64: http://swtch.com/libtask/ Regards, Jason On 13:12 Mon 09 Jan , Lionel Orry wrote: > Hi everyone, > > my company is currently developing a specific framework on SuperH > architectures (sh4) and I would like to investigate whether we could > use mongrel2 as part of it since it's highly client/server based and > needs good real-time performance, of course. So I'd like to know: > > - does any of you have an idea of the amount of work to get mongrel2 > working on SuperH? What are the architecture specific parts of it? I > suppose they are coupled to ZeroMQ. > - if that seems to much work, does any of you know whether ZeroMQ > alone is easy to port (or already ported) to SuperH architecture? > > A few missing details: I'm running a GNU/Linux with glibc (we don't > plan on using uclibc) on the sh4 so it's a pretty standard > configuration. > > Thanks for your feedbacks, > Lionel >
Hi Jason and Ivan, thank you both for your answers. I have a weird feeling, because (nearly) everything works out of the box... Not that I am unhappy about it, but seems to easy. - I have both libstdc++ and pthread on my box. Already using them both. - I could compile zeromq 2.1.11 as easily as on my x86. Nice. - I could compile mongrel2 1.7.5 just as easily, was a piece of cake. No relevant warnings in the src/task objects generation, only 2 small 'unused parameter' warnings. I also noticed that in my case, the preprocessor wiped away all content in src/task/asm.S, and asm.o is an empty object. But mongrel2 builds and links fine. - I could pass all zeromq tests - I could pass all tests from mongrel2. Can I conclude from those tests that the task library is functioning correctly? - I tried a sample deployment configuration and launched mongrel2 via m2sh. everything worked as expected, and I could send requests to served URLs to see mongrel2 react exactly the same as in the manual. So, how to say... it just works. Simply. No single modification in the code. Amazing. But I have the feeling that I will sooner or later get some issues related to the libtask stuff, so I'd like to know if you have advices on how to stress this interface... Create many handlers? What kind of handlers? Would it be interesting to augment the test suite with such stressing tests ? Thanks a lot, Lionel On Mon, Jan 9, 2012 at 6:16 PM, Jason Miller <jason@milr.com> wrote: > Hi Lionel, > > Mongrel2 relies on a cooperative multitasking library that would have to > be ported to SH; the CPU specific stuff is just basic context > save/restore, so it shouldn't be too hard. > > The mongrel libtask is based off of Russ Cox's libtask, which has been > ported to mips and power as well as x86/x86_64: > http://swtch.com/libtask/ > > Regards, > Jason > > On 13:12 Mon 09 Jan , Lionel Orry wrote: >> Hi everyone, >> >> my company is currently developing a specific framework on SuperH >> architectures (sh4) and I would like to investigate whether we could >> use mongrel2 as part of it since it's highly client/server based and >> needs good real-time performance, of course. So I'd like to know: >> >> - does any of you have an idea of the amount of work to get mongrel2 >> working on SuperH? What are the architecture specific parts of it? I >> suppose they are coupled to ZeroMQ. >> - if that seems to much work, does any of you know whether ZeroMQ >> alone is easy to port (or already ported) to SuperH architecture? >> >> A few missing details: I'm running a GNU/Linux with glibc (we don't >> plan on using uclibc) on the sh4 so it's a pretty standard >> configuration. >> >> Thanks for your feedbacks, >> Lionel >> >
Hi Lionel, I dug deeper into linux linkage and it turns out that glibc provides save/restore context functions that libtask uses on all targets except ARM. I'm not sure why it uses it's own thing on ARM, but *shrug*. BSD uses the handwritten assembly still though, but that shouldn't matter to you. -Jason On 09:57 Tue 10 Jan , Lionel Orry wrote: > Hi Jason and Ivan, > > thank you both for your answers. > > I have a weird feeling, because (nearly) everything works out of the > box... Not that I am unhappy about it, but seems to easy. > > - I have both libstdc++ and pthread on my box. Already using them both. > - I could compile zeromq 2.1.11 as easily as on my x86. Nice. > - I could compile mongrel2 1.7.5 just as easily, was a piece of cake. > No relevant warnings in the src/task objects generation, only 2 small > 'unused parameter' warnings. I also noticed that in my case, the > preprocessor wiped away all content in src/task/asm.S, and asm.o is an > empty object. But mongrel2 builds and links fine. > - I could pass all zeromq tests > - I could pass all tests from mongrel2. Can I conclude from those > tests that the task library is functioning correctly? > - I tried a sample deployment configuration and launched mongrel2 via > m2sh. everything worked as expected, and I could send requests to > served URLs to see mongrel2 react exactly the same as in the manual. > > So, how to say... it just works. Simply. No single modification in the > code. Amazing. But I have the feeling that I will sooner or later get > some issues related to the libtask stuff, so I'd like to know if you > have advices on how to stress this interface... Create many handlers? > What kind of handlers? Would it be interesting to augment the test > suite with such stressing tests ? > > Thanks a lot, > Lionel > > On Mon, Jan 9, 2012 at 6:16 PM, Jason Miller <jason@milr.com> wrote: > > Hi Lionel, > > > > Mongrel2 relies on a cooperative multitasking library that would have to > > be ported to SH; the CPU specific stuff is just basic context > > save/restore, so it shouldn't be too hard. > > > > The mongrel libtask is based off of Russ Cox's libtask, which has been > > ported to mips and power as well as x86/x86_64: > > http://swtch.com/libtask/ > > > > Regards, > > Jason > > > > On 13:12 Mon 09 Jan , Lionel Orry wrote: > >> Hi everyone, > >> > >> my company is currently developing a specific framework on SuperH > >> architectures (sh4) and I would like to investigate whether we could > >> use mongrel2 as part of it since it's highly client/server based and > >> needs good real-time performance, of course. So I'd like to know: > >> > >> - does any of you have an idea of the amount of work to get mongrel2 > >> working on SuperH? What are the architecture specific parts of it? I > >> suppose they are coupled to ZeroMQ. > >> - if that seems to much work, does any of you know whether ZeroMQ > >> alone is easy to port (or already ported) to SuperH architecture? > >> > >> A few missing details: I'm running a GNU/Linux with glibc (we don't > >> plan on using uclibc) on the sh4 so it's a pretty standard > >> configuration. > >> > >> Thanks for your feedbacks, > >> Lionel > >> > >
Hi, just a small followup on this subject. First thank you Jason for investigating, I came to the same conclusions as you and it does make me happy, no code to port at all. I've been experimenting a bit with Mongrel2 on my sh4 platform and it performs perfectly for now, though I've not stressed it with heavy load or peformance measurements. Those are not critical for me anyway, I might have 3 or 4 handlers only at the end and no more than 20 clients connected to the platform. But I truly like the http parser layer which will allow for good security, and easy routing to my handlers which will be written in C (I'll use libm2handler (https://github.com/xrl/libm2handler) and will try to make it evolve). So in summary : mongrel2 in embedded systems == the way to go ! Yay ! Another situation where m2 wins. Kind regards, Lionel On Tue, Jan 10, 2012 at 10:02 PM, Jason Miller <jason@milr.com> wrote: > Hi Lionel, > > I dug deeper into linux linkage and it turns out that glibc provides > save/restore context functions that libtask uses on all targets except > ARM. I'm not sure why it uses it's own thing on ARM, but *shrug*. BSD > uses the handwritten assembly still though, but that shouldn't matter to > you. > > -Jason > > On 09:57 Tue 10 Jan , Lionel Orry wrote: >> Hi Jason and Ivan, >> >> thank you both for your answers. >> >> I have a weird feeling, because (nearly) everything works out of the >> box... Not that I am unhappy about it, but seems to easy. >> >> - I have both libstdc++ and pthread on my box. Already using them both. >> - I could compile zeromq 2.1.11 as easily as on my x86. Nice. >> - I could compile mongrel2 1.7.5 just as easily, was a piece of cake. >> No relevant warnings in the src/task objects generation, only 2 small >> 'unused parameter' warnings. I also noticed that in my case, the >> preprocessor wiped away all content in src/task/asm.S, and asm.o is an >> empty object. But mongrel2 builds and links fine. >> - I could pass all zeromq tests >> - I could pass all tests from mongrel2. Can I conclude from those >> tests that the task library is functioning correctly? >> - I tried a sample deployment configuration and launched mongrel2 via >> m2sh. everything worked as expected, and I could send requests to >> served URLs to see mongrel2 react exactly the same as in the manual. >> >> So, how to say... it just works. Simply. No single modification in the >> code. Amazing. But I have the feeling that I will sooner or later get >> some issues related to the libtask stuff, so I'd like to know if you >> have advices on how to stress this interface... Create many handlers? >> What kind of handlers? Would it be interesting to augment the test >> suite with such stressing tests ? >> >> Thanks a lot, >> Lionel >> >> On Mon, Jan 9, 2012 at 6:16 PM, Jason Miller <jason@milr.com> wrote: >> > Hi Lionel, >> > >> > Mongrel2 relies on a cooperative multitasking library that would have to >> > be ported to SH; the CPU specific stuff is just basic context >> > save/restore, so it shouldn't be too hard. >> > >> > The mongrel libtask is based off of Russ Cox's libtask, which has been >> > ported to mips and power as well as x86/x86_64: >> > http://swtch.com/libtask/ >> > >> > Regards, >> > Jason >> > >> > On 13:12 Mon 09 Jan , Lionel Orry wrote: >> >> Hi everyone, >> >> >> >> my company is currently developing a specific framework on SuperH >> >> architectures (sh4) and I would like to investigate whether we could >> >> use mongrel2 as part of it since it's highly client/server based and >> >> needs good real-time performance, of course. So I'd like to know: >> >> >> >> - does any of you have an idea of the amount of work to get mongrel2 >> >> working on SuperH? What are the architecture specific parts of it? I >> >> suppose they are coupled to ZeroMQ. >> >> - if that seems to much work, does any of you know whether ZeroMQ >> >> alone is easy to port (or already ported) to SuperH architecture? >> >> >> >> A few missing details: I'm running a GNU/Linux with glibc (we don't >> >> plan on using uclibc) on the sh4 so it's a pretty standard >> >> configuration. >> >> >> >> Thanks for your feedbacks, >> >> Lionel >> >> >> > >
Hi Lionel, Great to hear you'll be using libm2handler! Let me know if you have any issues, I'd be glad to help. Good luck! Xavier On Fri, Jan 20, 2012 at 12:22 AM, Lionel Orry <lionel.orry@gmail.com> wrote: > Hi, > > just a small followup on this subject. > > First thank you Jason for investigating, I came to the same > conclusions as you and it does make me happy, no code to port at all. > > I've been experimenting a bit with Mongrel2 on my sh4 platform and it > performs perfectly for now, though I've not stressed it with heavy > load or peformance measurements. Those are not critical for me anyway, > I might have 3 or 4 handlers only at the end and no more than 20 > clients connected to the platform. But I truly like the http parser > layer which will allow for good security, and easy routing to my > handlers which will be written in C (I'll use libm2handler > (https://github.com/xrl/libm2handler) and will try to make it evolve). > > So in summary : mongrel2 in embedded systems == the way to go ! Yay ! > Another situation where m2 wins. > > Kind regards, > Lionel > > On Tue, Jan 10, 2012 at 10:02 PM, Jason Miller <jason@milr.com> wrote: > > Hi Lionel, > > > > I dug deeper into linux linkage and it turns out that glibc provides > > save/restore context functions that libtask uses on all targets except > > ARM. I'm not sure why it uses it's own thing on ARM, but *shrug*. BSD > > uses the handwritten assembly still though, but that shouldn't matter to > > you. > > > > -Jason > > > > On 09:57 Tue 10 Jan , Lionel Orry wrote: > >> Hi Jason and Ivan, > >> > >> thank you both for your answers. > >> > >> I have a weird feeling, because (nearly) everything works out of the > >> box... Not that I am unhappy about it, but seems to easy. > >> > >> - I have both libstdc++ and pthread on my box. Already using them both. > >> - I could compile zeromq 2.1.11 as easily as on my x86. Nice. > >> - I could compile mongrel2 1.7.5 just as easily, was a piece of cake. > >> No relevant warnings in the src/task objects generation, only 2 small > >> 'unused parameter' warnings. I also noticed that in my case, the > >> preprocessor wiped away all content in src/task/asm.S, and asm.o is an > >> empty object. But mongrel2 builds and links fine. > >> - I could pass all zeromq tests > >> - I could pass all tests from mongrel2. Can I conclude from those > >> tests that the task library is functioning correctly? > >> - I tried a sample deployment configuration and launched mongrel2 via > >> m2sh. everything worked as expected, and I could send requests to > >> served URLs to see mongrel2 react exactly the same as in the manual. > >> > >> So, how to say... it just works. Simply. No single modification in the > >> code. Amazing. But I have the feeling that I will sooner or later get > >> some issues related to the libtask stuff, so I'd like to know if you > >> have advices on how to stress this interface... Create many handlers? > >> What kind of handlers? Would it be interesting to augment the test > >> suite with such stressing tests ? > >> > >> Thanks a lot, > >> Lionel > >> > >> On Mon, Jan 9, 2012 at 6:16 PM, Jason Miller <jason@milr.com> wrote: > >> > Hi Lionel, > >> > > >> > Mongrel2 relies on a cooperative multitasking library that would have > to > >> > be ported to SH; the CPU specific stuff is just basic context > >> > save/restore, so it shouldn't be too hard. > >> > > >> > The mongrel libtask is based off of Russ Cox's libtask, which has been > >> > ported to mips and power as well as x86/x86_64: > >> > http://swtch.com/libtask/ > >> > > >> > Regards, > >> > Jason > >> > > >> > On 13:12 Mon 09 Jan , Lionel Orry wrote: > >> >> Hi everyone, > >> >> > >> >> my company is currently developing a specific framework on SuperH > >> >> architectures (sh4) and I would like to investigate whether we could > >> >> use mongrel2 as part of it since it's highly client/server based and > >> >> needs good real-time performance, of course. So I'd like to know: > >> >> > >> >> - does any of you have an idea of the amount of work to get mongrel2 > >> >> working on SuperH? What are the architecture specific parts of it? I > >> >> suppose they are coupled to ZeroMQ. > >> >> - if that seems to much work, does any of you know whether ZeroMQ > >> >> alone is easy to port (or already ported) to SuperH architecture? > >> >> > >> >> A few missing details: I'm running a GNU/Linux with glibc (we don't > >> >> plan on using uclibc) on the sh4 so it's a pretty standard > >> >> configuration. > >> >> > >> >> Thanks for your feedbacks, > >> >> Lionel > >> >> > >> > > > >
Hi Lionel, 2012/1/9 Lionel Orry <lionel.orry@gmail.com>: > - does any of you have an idea of the amount of work to get mongrel2 > working on SuperH? What are the architecture specific parts of it? I > suppose they are coupled to ZeroMQ. > A few missing details: I'm running a GNU/Linux with glibc (we don't > plan on using uclibc) on the sh4 so it's a pretty standard > configuration. Do you have pthreads and stdc++ on sh4? If yes, just try to build zeromq and run all of its tests (both "make check" and the performance tests [1]). In case of any problems ask on zeromq-dev mailing list or in IRC [2] - 0MQ people are very helpful . [1] http://www.zeromq.org/results:perf-howto [2] http://www.zeromq.org/intro:ask-for-help