From: Daniel Amelang Date: 2005-08-02T06:55:18+09:00 Subject: Re: Ruby in embedded applications > Dan, > thanks for your response. Embedded isn't all RTOS - our network > products have some RTOS stuff on them (anything involving GSM / GPRS > has some pretty tight timing windows), but a lot of it has no strict > real time limits. So I guess I'm interested in where and how Ruby could > be used in an emedded context. My guess is wherever you don't need tight timing windows :) Interfacing with the hardware at the very low level (like reading from/writing to specific hard-wired memory addresses) is a harder too (in ruby) but I guess you could create a C extension for that, too. > Why do you think that native threading is so important? All the embedded development I do is on a RTOS, where you have a large number of threads running concurrently (normally waiting on their various signals/interrupts). Ruby currently couldn't reproduce this behavior because it doesn't have native threads. You can't simultaneously block on multiple interrupts in ruby. Even if I spawned the native threads in a C extension, I'd run into problems because ruby isn't reentrant. Just think of all the async signals in a typical RTOS app. Your ISRs can't run any ruby code because of the lack of reentracy in the interpreter. Even with reentracy, you'll end up writing C extensions for interfacing with your IO devices, handling your interrupts, and your tight timing windows. By then, you may have run out of parts of your app to code in ruby. Maybe not. For what I've done in the embedded world, there hasn't been much left for ruby to do. But, like I said in my first post, (and you pointed out in your reply), my scenario is not representative of all embedded development. I'm just responding to your survey. Dan