• 0 Posts
  • 6 Comments
Joined 2 years ago
Cake day: June 3rd, 2023
  • AndrasKrigare@beehaw.orgtoLinux@lemmy.ml•Is Ctrl+D really like Enter?
    2·
    3 days ago

    To me, the potential point of confusion is referring to “sent by Ctrl+D” and things “received by the end process” as synonymous, ignoring the tty driver in between. When you Ctrl+d, you send a magic byte value to the tty master (which I would refer to as a EOF character, but I understand the argument against the terminology). On the other side of it the process doesn’t receive this value, but instead has its read call returned even if the buffer is 0.

    A simple example hopefully highlighting the difference

    Window1:
nc -nvlp 5555 #"far nc"

Window2:
nc -nv 127.0.0.1 5555 #"local NC"
Hi there[Enter]
Hi [Ctrl+D]There[Ctrl+D][Enter]

Window3:
strace -p [pid of local nc]

Window2:
[Right arrow][Right arrow][Ctrl+D]
[Ctrl+D]Uh oh[Enter]

    What we see is pretty much as described. From the first line, we see “Hi there\n” on the other side. For the second line, we first see "Hi " appear, then “There” then “\n”.

    From the third line, in the strace we can see the sequences representing the right-arrow key, and we can see the tty driver on the far side takes those sequences and interprets them to render the cursor two characters to the right.

    The fourth line is where it gets more interesting. We send the tty driver the EOF byte, and the tty driver interprets this and gives the current active tty client a 0-byte return to read() and assumes we have no more data to send. But unlike bash, nc doesn’t care about a 0-byte read and is still looking for more data (as we can see in the strace). But if we continue to type and send more data (the “Uh oh”), we can see in the strace that the tty never sends this to the nc. So, to some definition, we’re still sending data to the local nc, but the tty driver isn’t actually relaying it

  • AndrasKrigare@beehaw.orgtoProgrammer Humor@programming.dev•Synapse is the epitome of this
    1·
    5 days ago

    I haven’t heard of that being what threading is, but that threading is about shared resourcing and memory space and not any special relationship with the scheduler.

    Per the wiki:

    On a multiprocessor or multi-core system, multiple threads can execute in parallel, with every processor or core executing a separate thread simultaneously; on a processor or core with hardware threads, separate software threads can also be executed concurrently by separate hardware threads.

    https://en.m.wikipedia.org/wiki/Thread_(computing)

    I also think you might be misunderstanding the relationship between concurrency and parallelism; they are not mutually exclusive. Something can be concurrent through parallelism, as the wiki page has (emphasis mine):

    Concurrency refers to the ability of a system to execute multiple tasks through simultaneous execution or time-sharing (context switching), sharing resources and managing interactions.

    https://en.m.wikipedia.org/wiki/Concurrency_(computer_science)

  • AndrasKrigare@beehaw.orgtoProgrammer Humor@programming.dev•Synapse is the epitome of this
    3·
    6 days ago

    If what you said were true, wouldn’t it make a lot more sense for OP to be making a joke about how even if the source includes multi threading, all his extra cores are wasted? And make your original comment suggesting a coding issue instead of a language issue pretty misleading?

    But what you said is not correct. I just did a dumb little test

    import threading 
import time

def task(name):
  time.sleep(600)

t1 = threading.Thread(target=task, args=("1",))
t2 = threading.Thread(target=task, args=("2",))
t3 = threading.Thread(target=task, args=("3",))

t1.start()
t2.start()
t3.start()

    And then ps -efT | grep python and sure enough that python process has 4 threads. If you want to be even more certain of it you can strace -e clone,clone3 python ./threadtest.py and see that it is making clone3 syscalls.