Hi Sven,
> Dealing with a set of IO channels using 1 thread/process per channel
> like you describe should not be a problem. To do it efficiently, you
> have to consider if the low level API you are dealing with is
> blocking or not. If it is blocking (optionally with a timeout), like
> for sockets, there is no problem. If it is non-blocking, you can
> easily built something around it using delays and some polling at a
> reasonable values. If have no experience with serial ports, so I
> can't offer any specific advice there. For TCP/UDP networking there
> shouldn't be any problem. Feel free to ask concrete questions.
Thanks for all the tips. The current VM Implementation is non-blocking -
e.g. return an empty byte array if nothing was recieved. So my procecces
(per port) are polling seperated by calls to Delay.
BTW: Does "(Delay forMilliseconds: time) wait" actually "cost" something
in terms of CPU cycles. Reading through the comments I got the
impression that besides delaying the current process it doesn't cause
any penalty for other processes.
Best Regards,
Udo
On 27.10.12 17:45, Sven Van Caekenberghe wrote:
Hi Udo,
Yes, Smalltalk is a very nice environment to work in, it is only natural to try
to do as much work in it as possible.
It looks like you are doing a nice, interesting project ;-)
As a language/environment born in a time when computing resources were very
small compared to what we have today, you can rest assured that Smalltalk can
keep up performance wise with almost any other language out there, especially
JavaScript, Ruby, Python, PHP or Perl.
Dealing with a set of IO channels using 1 thread/process per channel like you
describe should not be a problem. To do it efficiently, you have to consider if
the low level API you are dealing with is blocking or not. If it is blocking
(optionally with a timeout), like for sockets, there is no problem. If it is
non-blocking, you can easily built something around it using delays and some
polling at a reasonable values. If have no experience with serial ports, so I
can't offer any specific advice there. For TCP/UDP networking there shouldn't
be any problem. Feel free to ask concrete questions.
Regards,
Sven
--
Sven Van Caekenberghe
http://stfx.eu
Smalltalk is the Red Pill
On 27 Oct 2012, at 10:09, Udo Schneider
<[email protected]> wrote:
All,
coming from a Node.JS background for those kind of tasks I'm not quite sure how to do it
"correctly" in Pharo. I need to
* listen on up to 32 serial (USB) ports for incoming commands. Each might use a different
"protocol".
* listen to network ports, midi channels or OSC
* if communication is received then a response could be send over multiple of
the channels mentioned above
* reaction time - means incomming message, decode, encode of response and
distribution over other channels should ideally be around 10^-2 s.
I already found all the necessary communication classes in Pharo - and being
back in Smalltalk again parsing the commands is a real pleasure :-) The one
thing that makes me really nervous though is serial support. Up to now I spawn
a separate (Smalltalk) process for each serial port that polls the serial port
for new bytes - as far as I see polling is the only available option. Although
this seems to work it wastes a considerable amount of CPU cycles IMHO. On my
current system (MBP/i7) I can't have enough channels to even barely bog the
system down. However the deployment platform I'm looking at is more in the
range of an Raspberry Pi...
In Node.JS I'd simply create callbacks for all the different incoming channels
- so I wouldn't waste cycles for polling. So what would be the best/recommended
way to achieve this in Pharo?
Thanks,
Udo
