Please forgive me if I do not use the correct terminology, or have some convoluted thoughts. I am not certain at all about this subject which is why I have created this conversation.
I am working on an app that consists of several parts/functions. The major parts of this are:
Serial Loop to poll external hardware devices
The app Loops using serial port to poll several external hardware devices. Each are polled by the app one at a time, and respond only when their specific address is used. They then respond with data that is decoded and checked using a SQLite database. Depending on the result of that work, one or more commands may be sent out to one or more of the external devices.
This process needs to run continuous, and as fast as possible forever, without interruption (or as little as possible).
TCP Server - Listens for user connections. This is the method by which the user will make changes to the database - which controls the polling of devices like which address to poll - and also to request/get updates from the database so that information may be used for reporting and other GUI/User information.
TCP Client - logs into a Webserver to send and retrieve certain data like licenses. It may also send updates similar to what is provided to the user connections, but to the webserver.
Each of these three elements are contained within a single Console project. Items 2 & 3 are together in a Module. Item 1 is also in its own module. They are not completely separated since some events, either unidirectional or bidirectional are in place and are necessary.
My question surrounds how best to use a multicore processor, and/or allow each of these to operate basically independantly of each other. In addition to the 3 items above, possibly another TCP Client OR Server may become necessary.
One of the reasons I have to add one or more additional modules, is to limit interruption of the first three core elements.
I am not really sure if segregation has not already been achieved simply due to the design AND the thought that each instance of a TCP Server, will be in its own thread automatically. Same with the Client. When they are created, the action of creating a New TCP Client creates the new object in its own thread and stack space. Is that correct?
Can anyone enlighten me a bit further on the above?
Thanks all,
Tim
A single xojo executable will never use more than a single cpu core. And everything that happens in that executable, while it may happen asynchronously from each other, all happens in sequence on that one core. In addition to that, all the DataAvailable events of the serial port and all the sockets execute on the main thread and each one will block all the others until it completes. Then the next one will get a chance to run and it will block all the others until it completes, etc. So you don’t really get any additional threading out of TCP sockets, other than the low-level, interrupt-driven I/O services, which ensure that communication takes place.
If you want to take advantage of multiple cores and protect each subsystem from interference from the others, you should make each one a separate executable and have them communicate via sockets or through writing messages to the database.
I would suggest to put the serial polling in a helper app so it’s not blocked by a msgbox or anything else.
You can talk from this app via IPCSocket to other app doing the other stuff.
Shouldnt this be possible by creating a timer-polled socket that parses the incoming data? I have done so in my current first app and just checked it out: While I had a messagebox open on screen, an incoming call was picked up and announced though. This is much less hassle than creating a helper app, it seems to me.
If timing is critical - you’ve stated that the serial communications must happen quickly, with as little delay as possible - your best bet is to create a helper app. The simple act of the user manipulating the UI could stop your application in its tracks; for example, if they were to press and hold a PushButton, the entire app might stop processing DataAvailable events. A helper app would not be restricted in this way.
Thx, Eric!
I just tried this in my app which communicates with a telephone through a threaded TCP-socket which is polled by a timer. The DataAvailable event invokes a parsing module inside the socket, and while I held down a pushbutton and called myself from my mobile phone, the incoming call was shown correctly inside the status window which updates itself through a timer, checking the data of a shared class of properties the socket writes to. But I can imagine there can be much more complex situations to handle in Tims application which my simple design could not stand to.
Anyway, Im glad I found this solution which gives me enough multitasking capabilities without having to design helper apps.
Currently, I have no problem with missing data in any part of the program I can get seemingly good and fast serial communications, but as the system gets more and more loaded, it does slow - but without any loss of data. This is obviously very very nice. However, the slowdown is not excessive, so performance is acceptable. However when compared to initial bench marks - which were not nearly as loaded as the real thing, performance in comparison IS obviously different.
When the design was originally conceived, and as programming/development progressed, it became apparent that performance could take a significant hit, due entirely to design. This, unfortunately, has happened due to my inexperience and lack of understanding RS/Xojo back then, and also of OOP…
So, while it does work, what I want to do is to take the ‘learned curve’ and the advice of the nice and helpful Xojo community and incorporate that into further extensions - items that were not part of the original design. Then later, the now existing parts of the app can be broken apart to take further advantage of these same things.
Thanks again for all of your replies! I truly do appreciate all of the feed back!
Tim
I can get seemingly good and fast serial communications, but as the system gets more and more loaded, it does slow - but without any loss of data. This is obviously very very nice. However, the slowdown is not excessive, so performance is acceptable. However when compared to initial bench marks - which were not nearly as loaded as the real thing, performance in comparison IS obviously different.