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 >> <[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 >>> >>> >> >> >> > > > -- Best regards, Igor Stasenko.
