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

Example Re: Tk with thread and stram data ( return ), Re^4: Perl/Tk vs Win32::SerialPort (stash, dispatch, queue)
  • Comment on Re: Tk and threads and Control::CLI- change Port-(Object) in Tk an let workers know

Replies are listed 'Best First'.
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.
      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.