running TCP Socket in background?

[meigrafd 0]

Hello.

 

Is it possible to run a Program (Daemon) in the Background, listening for TCP Connections ?

 

I read something about that its possible to have 4 threads (background tasks?) and i saw the linux like 'rc' stuff in OpenOS...

 

 

The intension is to have something like a relay script:

Daemon Script listens on special port for Connections; any Client-Script on same computer connects and if the Client then sends a special message the Daemon will relay it to IRC 

 

...i want to write a Script to control something and already have a while loop - and dont want to connect&send&disconnect; connect&send&disconnect etc. to irc each message 

[dgelessus 26]

OpenOS has no such thing as "background processes" - really all code is executed in a single thread. What you probably want is the event library's listen function, which allows you to register a listener that is called when the computer receives a given signal type.

I'm not sure if this works any differently with TCP sockets, I have no idea how to use those even in real life code. Someone else probably knows though.

[meigrafd 0]

Cant i do that with the RC and Process API ? 

 

 

The RC API allows the creation and management of services: programs that run in the background and provide various functionality. Daemons in UNIX parlance.

 

[dgelessus 26]

rc allows you to manage "service"-like programs in /etc/rc.d, control which ones are started on boot, and lets you send commands to the services. It doesn't provide any way of running programs in the background.

process is used to load other executable files as coroutines and keeps track of what program a coroutine was created by. process.load returns a normal coroutine, which you still have to run yourself. In Lua there can only be a single running coroutine at a time, which means that you cannot make background processes with this either.

 

event.listen doesn't create any background processes either. It lets you register functions that are called whenever a certain signal type is received. It might seem like the signal receiving happens in the background, but it doesn't. At the lowest level signals are received using computer.pullSignal, which waits for any kind of signal and returns it. The event library builds on top of that - event.pull calls computer.pullSignal multiple times until the desired signal is received, and also calls any registered signal listeners for all received signals, and runs timers when they are due. No background process "magic" going on there.