Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know

notworx has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks, I tried to ask in the Chatterbox, but I run out of charakters. I hope that it is allowed to ask here for help instead. I'm new to Perl and programming and english :-P (sorry for that). Im trying to read/write Serial Data and show them with Tk. I am using threads (one for read and one for write (because Non-blocking reading was impossible for me without threads)). I learned that threads have to be created before Tk starts. My Problem is the following: I want to be able to change/start the COM-Port from Tk.

my $PortObj = new Control::CLI (Use => $PortName);
[download]

but then I have to transfer the new $PortObj to the already running worker-threads. How would you do that? If I do in this order: $PortObj > workers > Tk-gui -> everything works fine. But $PortObj > workers > Tk-gui > "change PortObject and give new one to the worker-threads" fails. I tried many different things (please remember I am newbie) for example:
giving $PortObj by :shared var, to workers
giving $PortObj by queue, to workers
giving $PortObj by queue "freeze $PortObj" using Storable to workers
that all failed. My scripts normally get to work by

until ($everything_works){
try; 
error;
read the Manual; 
google;
}
[download]

but this time I think I need an advice. Thank you in advance!!! Best regards Stefan.

Comment on Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know Select or Download Code

Replies are listed 'Best First'.
Re: Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know by Anonymous Monk on Mar 11, 2023 at 11:46 UTC
Example Re: Tk with thread and stram data ( return ), Re^4: Perl/Tk vs Win32::SerialPort (stash, dispatch, queue)	[reply]
Re^2: Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know by notworx (Novice) on Mar 11, 2023 at 13:35 UTC
Thank you, what I understand is that I should say the worker "connect to a different Port". Then I have a new problem: I need two workers using the same COM-Port. I think it is impossible to let two workers connect to the same port. The reason for the two workers: With two workers reading & writing is possible at the same time. With just one worker every read, blocks writing for about one second. I tried for hours to make it non-blocking and then decided to use threads (and that really worked well). I am not sure, but I think generating workers first, then Tk has the following reason: The copy of everything in memory (when generating the threads) disturbs Tk. (https://www.perlmonks.org/?node_id=585533) I think the use of fork() would lead to the same Problem I think the solution i should try, is to have two seperate scripts running (one for Tk and one for the I/O). Therefore i read a lot about IPC today, but ran into many traps. Not using fork seems to make "easy" IPC impossible (or am I wrong?) What is the easiest way to let two seperate Perl-Scripts "talk" to each other? Unix Domain Sockets seem not to work on Windows. I am willing to read, learn and try a lot but at moment everything seems to lead to new problems far beyond my knowledge. EDIT: I found solutions. No more threads in Tk script... open3 opens the script (from gui) for serial I/O. The new difficulty was to read non-blocking from that so gui won't freeze: Solution: gui asks second script for the number of answers it will deliver, second script answers with number. gui reads just #number times.(so that there is definitly an answer) Then display, then redo. Works for now... But now I have to understand how to work with errors on a script started by "open3" (But I'm really happy that it is possible) I love Perl because it really keeps easy things easy and makes impossible things possible. A workmate asked me "why I learn such an old language" - and I really had enough answers. No answer for me here but also no "RTFM you idiot" I think thats very special to the Perl community - Thank you all for that.	[reply]
Re^3: Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know by Marshall (Canon) on Mar 13, 2023 at 17:00 UTC
You should be able to run the serial ports without needing threads. The main mechanism from Tk is that you can have a subroutine called every x ms. That sub services the ports using non-blocking calls. As long as you do what you need within the sub quickly (less than several hundred ms), all will be fine. If you want some help on that please show your serial port code. It would be helpful if you explained a bit more about the protocol that you are using over the serial port. And a bit more about how the GUI fits into what the application does. I'm not sure what you are doing with this other script that you call with open3. Again some code would be helpful.	[reply]
Re: Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know by jmlynesjr (Deacon) on Mar 14, 2023 at 01:26 UTC
Look at Tk fileevent, after, and repeat. Perl Tk fileevent James There's never enough time to do it right, but always enough time to do it over...	[reply]