Hi Igor
I should have written process with a capital "P". I meant the Smalltalk
class "Process" - a OS process :-)
Best Regards,
Udo
On 28.10.12 17:44, Igor Stasenko wrote:
On 28 October 2012 10:45, Udo Schneider
<[email protected]> wrote:
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.
it doesn't.
smalltalk employs green threading model.
while js dont even have a notion of a process (thread) in language.
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
<udo.schneider-1km8gppntmzsorrrgtp2kg-xmd5yjdbdmrexy1tmh2...@public.gmane.org>
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
