Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:
> Quote: < process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
>
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving birth to a child process
> and one which replaces the original process effectively giving its
> parent a death sentence?

The difference is that the second case doesn't occur. You can think of
'a process' as sort-of a container the kernel uses for running a
program: In order to execute a specific program, it has to be put into a
process first and that's what the exec* calls do. They load a new
program/ executable file into an existing process so that it will be
executed instead of the program the process had been executing so far.

The complete list of modifications an existing process undergoes when
starting to run a new program is in execve(2) ('man 2 execve').
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[ibid . ag]

On Sat, Sep 05, 2015 at 08:52:39PM +0100, Edward Bartolo wrote:
> Quote: < process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
> 
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving birth to a child process
> and one which replaces the original process effectively giving its
> parent a death sentence?
> 
> Sorry, but it looks there is only a very subtle difference between the
> two. The only difference I see, is that, since in the case of execl,
> the parent effectively is replaced, i.e. dies, it is also awarded its
> parent PID. This is not the case when a parent process creates a child
> process and exits immediately, as the child will have a different PID.

A program that runs via execlp()--or any of the exec*() functions--
*is* the process that called execlp().
It does not kill the *process*, though it effectively ends the
*program*.
As a result, it has the same parent as the previous program.
(This is why you can run "exec killall forkbomb" to kill a forkbomb,
at the expense of one shell.)

To create a *new* process, you use fork(), vfork(), posix_spawn(),
popen(), or system().

In C, system() is the recommended, portable way to run programs; it
forks, execs "sh -c COMMAND", waits, and returns the exit status.

popen() is the recommended approach if you want to use a stream.
It creates a pipe, forks, and runs "sh -c COMMAND" in the child.
The parent then returns a FILE pointer to the stream.
Once you have done the desired IO on the stream, you can call
pclose(), which will take care of closing the pipe, waiting for the
child, and finally return the child status.

If you want to avoid zombies simply, just use popen() and pclose().

HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[KatolaZ]

On Sat, Sep 05, 2015 at 08:52:39PM +0100, Edward Bartolo wrote:
> Quote: < process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
> 
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving birth to a child process
> and one which replaces the original process effectively giving its
> parent a death sentence?


??? 

I think there is here some confusion about process creation. Upon a
fork() the process calling it (the parent) is effectively *copyed*
into a new process (the child). The child is an (almost, up to few
details) *exact* copy of the parent, including the program page (the
code). Hence, by calling execve in the child you are not "giving its
parent a death sentence" but you are simply replacing the progam page
(the code) of the child process. The parent is unaffected by such a
call, because it does not occur in its process space. 

I warmly suggest you to have a look to something like "The Linux
Programming Interface":

   http://man7.org/tlpi/

Incidentally, the pdf of the chapter related to process creation is
available for download:

   http://man7.org/tlpi/download/TLPI-24-Process_Creation.pdf

My2cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Correction:

Sorry, but it looks there is only a very subtle difference between the
two. The only difference I see, is that, since in the case of execl,
the parent effectively is replaced, i.e. dies, the child process is awarded its
parent PID. This is not the case when a parent process creates a child
process and exits immediately, as the child will have a different PID.



On 05/09/2015, Edward Bartolo  wrote:
> Quote: < a
> process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.>>
>
> So what is the difference between an "orphaned process", i.e. a
> process whose parent has exited after giving birth to a child process
> and one which replaces the original process effectively giving its
> parent a death sentence?
>
> Sorry, but it looks there is only a very subtle difference between the
> two. The only difference I see, is that, since in the case of execl,
> the parent effectively is replaced, i.e. dies, it is also awarded its
> parent PID. This is not the case when a parent process creates a child
> process and exits immediately, as the child will have a different PID.
>
> On 05/09/2015, Rainer Weikusat  wrote:
>> Edward Bartolo  writes:
>>
>> [...]
>>
>>> Using "ps xao pid,ppid,comm", I found what I described to you:
>>> precisely, that orphaned processes were adopted by the GUI frontend.
>>
>> There are no 'orphaned processes' in this case because execl does not
>> create a new process. It runs a new program in the same process and
>> since the parent of this process was the frontend process before the
>> execl, it's still the parent of this process afterwards.
>>
>> An 'orphaned process' is one whose parent has exited after creating a
>> process (that's done via fork and not via execve) and it's not adopted
>> by the grand parent but by init.
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Quote: <>

So what is the difference between an "orphaned process", i.e. a
process whose parent has exited after giving birth to a child process
and one which replaces the original process effectively giving its
parent a death sentence?

Sorry, but it looks there is only a very subtle difference between the
two. The only difference I see, is that, since in the case of execl,
the parent effectively is replaced, i.e. dies, it is also awarded its
parent PID. This is not the case when a parent process creates a child
process and exits immediately, as the child will have a different PID.

On 05/09/2015, Rainer Weikusat  wrote:
> Edward Bartolo  writes:
>
> [...]
>
>> Using "ps xao pid,ppid,comm", I found what I described to you:
>> precisely, that orphaned processes were adopted by the GUI frontend.
>
> There are no 'orphaned processes' in this case because execl does not
> create a new process. It runs a new program in the same process and
> since the parent of this process was the frontend process before the
> execl, it's still the parent of this process afterwards.
>
> An 'orphaned process' is one whose parent has exited after creating a
> process (that's done via fork and not via execve) and it's not adopted
> by the grand parent but by init.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:

[...]

> Using "ps xao pid,ppid,comm", I found what I described to you:
> precisely, that orphaned processes were adopted by the GUI frontend.

There are no 'orphaned processes' in this case because execl does not
create a new process. It runs a new program in the same process and
since the parent of this process was the frontend process before the
execl, it's still the parent of this process afterwards.

An 'orphaned process' is one whose parent has exited after creating a
process (that's done via fork and not via execve) and it's not adopted
by the grand parent but by init.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

First of all, thanks for taking the time to write to me.

Using "ps xao pid,ppid,comm", I found what I described to you:
precisely, that orphaned processes were adopted by the GUI frontend.
The frontend's pid was listed as the zombies' ppid. Now, this issue
has little effect on the code as I am using the WaitOnExit for any
behind the scenes processes. Using a second thread to call the
backend, enabled me to use WaitOnExit without affecting the frontend.

The pasted listing is a listing by ps. You can see that ifup, ifdown
and backend have actually inherited their grandfather's pid.

$ ps xao pid,ppid,comm
  PID  PPID COMMAND
1 0 init
2 0 kthreadd
3 2 ksoftirqd/0
5 2 kworker/0:0H
7 2 rcu_sched
8 2 rcu_bh
9 2 migration/0
   10 2 watchdog/0
   11 2 watchdog/1
   12 2 migration/1
   13 2 ksoftirqd/1
   15 2 kworker/1:0H
   16 2 khelper
   17 2 kdevtmpfs
   18 2 netns
   19 2 khungtaskd
   20 2 writeback
   21 2 ksmd
   22 2 khugepaged
   23 2 crypto
   24 2 kintegrityd
   25 2 bioset
   26 2 kblockd
   27 2 kworker/0:1
   28 2 kworker/1:1
   29 2 kswapd0
   30 2 fsnotify_mark
   36 2 kthrotld
   37 2 ipv6_addrconf
   38 2 kworker/0:2
   39 2 deferwq
   73 2 khubd
   76 2 acpi_thermal_pm
   77 2 ata_sff
   78 2 scsi_eh_0
   79 2 scsi_tmf_0
   80 2 scsi_eh_1
   81 2 scsi_tmf_1
   82 2 kworker/u8:2
   83 2 kworker/u8:3
   84 2 scsi_eh_2
   85 2 scsi_tmf_2
   86 2 scsi_eh_3
   87 2 scsi_tmf_3
   92 2 kworker/1:2
   94 2 kworker/1:1H
   95 2 kworker/0:1H
  117 2 jbd2/sda9-8
  118 2 ext4-rsv-conver
  308 1 udevd
  365 2 hd-audio0
  372 2 kpsmoused
  379 2 cfg80211
 1276 1 rpcbind
 1304 1 rpc.statd
 1309 2 rpciod
 1311 2 nfsiod
 1318 1 rpc.idmapd
 1555 1 privoxy
 1563 1 rsyslogd
 1601 1 atd
 1631 1 acpid
 1669 1 cron
 1727 1 dbus-daemon
 1969 1 exim4
 1989 1 slim
 2015  1989 Xorg
 2016 1 getty
 2017 1 getty
 2018 1 getty
 2019 1 getty
 2020 1 getty
 2021 1 getty
 2034 2 kauditd
 2036 1 console-kit-dae
 2103 1 polkitd
 2114  1989 sh
 2166  2114 ssh-agent
 2169 1 dbus-launch
 2170 1 dbus-daemon
 2180  2114 xfce4-session
 2182 1 xfconfd
 2186 1 gpg-agent
 2187  2180 xfwm4
 2189  2180 xfce4-panel
 2191 1 xfsettingsd
 2193 1 syndaemon
 2195  2180 xfdesktop
 2199 1 xfce4-power-man
 2203 1 xscreensaver
 2206 1 xfce4-power-man
 2209 1 xfce4-volumed
 2212 1 upowerd
 2223  2189 panel-6-systray
 2239  2189 panel-2-actions
 2377  2189 iceweasel
 2398 1 at-spi-bus-laun
 2407  2189 xchat
 2571 2 kworker/0:0
 2572 2 kworker/1:0
 2607 1 Thunar
 2611 1 tumblerd
 2616 1 netman
 2633  2616 backend 
 2643  2616 ifdown 
 2663 2 kworker/0:3
 2664 2 kworker/0:4
 2698 1 xfce4-terminal
 2702  2698 gnome-pty-helpe
 2703  2698 bash
 2791  2616 ifup 
 2801 1 wpa_supplicant
 2823 2 kworker/u8:0
 2843 1 dhclient
 3044  2703 ps

As you can see, the listed zombies have inherited their grandfather's
pid as their ppid.

On 05/09/2015, Rainer Weikusat  wrote:
> Edward Bartolo  writes:
>> I am not putting in doubt what you are telling me.
>
> You are. And you are - pardon my frankness - very much confused
> regarding how 'processes and process relationships' work on UNIX(*)/
> Linux. I'll try to clear this up but you might want to consider getting
> yourself a good book on the topic.
>
>> In my implementation, the backend is run from within the code of the
>> frontend, so its ppid is the pid of the frontend.
>
> This is correct.
>
>> Occurrences of execl, create another child process which is owned by
>> the backend, but the latter, dies as soon as the child process is
>> created.
>
> This isn't: execl doesn't create a child process associated with the
> process invoking it but it makes this process execute a new program. You
> can see this for yourself. Save the following two C source code files to
> some directory as a.c and b.c.
>
>  a.c -
> #include 
> #include 
>
> int main(void)
> {
> printf("I'm program-1, my pid is %lu and my parent is %lu\n", getpid(),
> getppid());
> execl("./program-2", "p2", (void *)0);
> return 0;
> }
> --
>
>  b.c 
> #include 
> #include 
>
> int main(void)
> {
> printf("I'm program-2, my pid is %lu and my parent is %lu\n", getpid(),
> getppid());
> return 0;
> }
> -
>
> compile them into exectuables named program-1 and program-2 via
>
> gcc -o program-1 a.c
> gcc -o program-2 b.c
>
> and run program-1. The output should be (with different actual pids, of
> course)
>
> [rw@doppelsaurus]/tmp#./program-1
> I'm program-1, my pid is 8935 and my parent is 3395
> I'm program-2, my pid is 8935 and my parent is 3395
>
>> The orphaned child is related to the f

Re: [DNG] Doing away with multi-threading in my project (netman)

[Nate Bargmann]

Edward,

A rather thorough reference is "The Linux Programming Interface"
available from:  http://www.man7.org/tlpi/  and other retailers.

HTH,

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:
> I am not putting in doubt what you are telling me.

You are. And you are - pardon my frankness - very much confused
regarding how 'processes and process relationships' work on UNIX(*)/
Linux. I'll try to clear this up but you might want to consider getting
yourself a good book on the topic.

> In my implementation, the backend is run from within the code of the
> frontend, so its ppid is the pid of the frontend.

This is correct.

> Occurrences of execl, create another child process which is owned by
> the backend, but the latter, dies as soon as the child process is
> created.

This isn't: execl doesn't create a child process associated with the
process invoking it but it makes this process execute a new program. You
can see this for yourself. Save the following two C source code files to
some directory as a.c and b.c.

 a.c -
#include 
#include 

int main(void)
{
printf("I'm program-1, my pid is %lu and my parent is %lu\n", getpid(), 
getppid());
execl("./program-2", "p2", (void *)0);
return 0;
}
--

 b.c 
#include 
#include 

int main(void)
{
printf("I'm program-2, my pid is %lu and my parent is %lu\n", getpid(), 
getppid());
return 0;
}
-

compile them into exectuables named program-1 and program-2 via

gcc -o program-1 a.c
gcc -o program-2 b.c

and run program-1. The output should be (with different actual pids, of
course)

[rw@doppelsaurus]/tmp#./program-1
I'm program-1, my pid is 8935 and my parent is 3395
I'm program-2, my pid is 8935 and my parent is 3395

> The orphaned child is related to the frontend, but its direct parent
> being dead, is assigned the pid of the frontend as its parent.

Orphaned child processes don't become children of the parent of their
original parent, they become children of init/
the-process-with-pid-1. init mostly just executes a wait-loop in order
to collect (and ignore) the exit status of any process assigned to it in
this way to prevent them from turning into zombies.

> The complications arise considering the fact, that the backend runs with root
> privileges,

[...]

> It seems, the fact that child processes created by instances of the
> backend, are thus owned by root, and the frontend is not permitted to
> wait() and reap them.

As the example program from my last mail should have demonstrated:
This is also wrong. A process can collect the status of one if its
children even if the child is executing under a different euid and if
this different euid happens to be 0.

BTW: Despite I don't have a WiFi-capable computer here, I cloned the
edbarx/netman.git repository to see if I could perhaps fix
this. However, the code available via

https://git.devuan.org/edbarx/netman.git

doesn't compile. The backend_src/bin and backend_src/obj directories are
missing. This is likely due to a misfeature (IMO) of all SCMs I've been
using so far, namely, they drop empty directories. You can avoid this by
creating a dummy file in both, eg,

touch backend_src/obj/.keep
touch backend_src/bin/.keep

and check them into git like this

git add backend_src/obj/.keep  backend_src/bin/.keep
git commit -a -m 'directories needed by the build system'

After doing this, the build aborts with

backend.pas(96,13) Error: Identifier not found "RunCommand"

(occurs a couple of times). I could fix this but since this seems like a
minor oversight to me, I suggest that you put the missing stuff into the
public repository instead.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

I am not putting in doubt what you are telling me. In my
implementation, the backend is run from within the code of the
frontend, so its ppid is the pid of the frontend. Occurrences of
execl, create another child process which is owned by the backend, but
the latter, dies as soon as the child process is created. The orphaned
child is related to the frontend, but its direct parent being dead, is
assigned the pid of the frontend as its parent. The complications
arise considering the fact, that the backend runs with root
privileges, while the frontend runs with normal user privileges. This
anomaly is achieved using a root SUID for the backend that permits a
normal user to run the backend with root privileges.

It seems, the fact that child processes created by instances of the
backend, are thus owned by root, and the frontend is not permitted to
wait() and reap them. This is why we ended up with zombies populating
the process list.

That is my humble explanation.

Edward

On 04/09/2015, Rainer Weikusat  wrote:
> Edward Bartolo  writes:
>> A periodic algorithm is now implemented in the frontend to search for
>> backend and any spawned children for ownership by root. This most
>> probably was what was causing waitpid and wait to fail to reap
>> zombies.
>
> It can't. As an experiment, copy the id program to /tmp and make it
> setuid-0:
>
> As root, run
>
> cp /usr/bin/id /tmp
> cd /tmp
> chmod u+s id
>
> Compile and run the following program in /tmp (as non-root user):
>
> --
> #include 
> #include 
> #include 
>
> int main(void)
> {
> int status;
>
> if (fork() == 0) execl("/tmp/id", "id", (void *)0);
>
> wait(&status);
> fprintf(stderr, "exit status %d\n", status);
>
> sleep(2);
> execlp("/bin/ps", "ps", "fax", (void *)0);
>
> return 0;
> }
> --
>
> This will print 'exit status 0', sleep for 2s and then display the ps
> fax process with no zombie attached to it. Repeat running the program
> but after recompiling it with the wait and fprintf lines commented
> out. This time, the ps fax output will show the 'defunct' id process as
> it's exit status hasn't been collected.
>
> There's of course a chance that the fpc libraries do something funky for
> such a case but I don't believe so.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:
> A periodic algorithm is now implemented in the frontend to search for
> backend and any spawned children for ownership by root. This most
> probably was what was causing waitpid and wait to fail to reap
> zombies.

It can't. As an experiment, copy the id program to /tmp and make it
setuid-0:

As root, run

cp /usr/bin/id /tmp
cd /tmp
chmod u+s id

Compile and run the following program in /tmp (as non-root user):

--
#include 
#include 
#include 

int main(void)
{
int status;

if (fork() == 0) execl("/tmp/id", "id", (void *)0);

wait(&status);
fprintf(stderr, "exit status %d\n", status);

sleep(2);
execlp("/bin/ps", "ps", "fax", (void *)0);

return 0;
}
--

This will print 'exit status 0', sleep for 2s and then display the ps
fax process with no zombie attached to it. Repeat running the program
but after recompiling it with the wait and fprintf lines commented
out. This time, the ps fax output will show the 'defunct' id process as
it's exit status hasn't been collected.

There's of course a chance that the fpc libraries do something funky for
such a case but I don't believe so.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Oooop, the algorithm is not periodic, but is used whenever the user
clicks connect and disconnect. Other operations can also be included.

On 04/09/2015, Edward Bartolo  wrote:
> A periodic algorithm is now implemented in the frontend to search for
> backend and any spawned children for ownership by root. This most
> probably was what was causing waitpid and wait to fail to reap
> zombies. If the algorithm find a root process parented by the
> frontend, it will disable 'connect' and 'disconnect' until the process
> dies. This prevents against having multiple threads initiated by
> impatient users.
>
> The next step is semi/automatic wifi connection.
>
>
> Edward
>
> On 04/09/2015, Rainer Weikusat  wrote:
>> Edward Bartolo  writes:
>>
>>> Hi,
>>>
>>> For the last days I have been struggling to reap zombies adopted by
>>> the frontend with only failures.
>>
>> The frontend doesn't adopt zombies. Only init ever does that.
>>
>>> I tried several methods using wait(-1), waidpid and trapping the
>>> signal when a child dies without ever succeeding to reap zombies. This
>>> means, I will stop and will leave the issue open to anyone who can
>>> find a working solution.
>>
>> The 'zombie reaping' needs to happen in the parent process. This means
>> the backend has to care for any processes it starts via fork. And the
>> frontend has to care for the backend. You can get a tree view of
>> processes via ps f, eg,
>>
>> ps fx
>>
>> to show all processed running under you current uid.
>>
>> [...]
>>
>>
>>> initialization
>>>
>>>   sa.sa_handler := @handle_sigchld;
>>
>> Insofar the documentation goes, you should be able to replace this with
>>
>> sa.sa_handler := SIG_IGN;
>>
>> this means now direct backend processes will ever be zombified. As the
>> backend is written in C, a single
>>
>> signal(SIGCHLD, SIG_IGN);
>>
>> will take care of all processes spawned by the backend.
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

A periodic algorithm is now implemented in the frontend to search for
backend and any spawned children for ownership by root. This most
probably was what was causing waitpid and wait to fail to reap
zombies. If the algorithm find a root process parented by the
frontend, it will disable 'connect' and 'disconnect' until the process
dies. This prevents against having multiple threads initiated by
impatient users.

The next step is semi/automatic wifi connection.


Edward

On 04/09/2015, Rainer Weikusat  wrote:
> Edward Bartolo  writes:
>
>> Hi,
>>
>> For the last days I have been struggling to reap zombies adopted by
>> the frontend with only failures.
>
> The frontend doesn't adopt zombies. Only init ever does that.
>
>> I tried several methods using wait(-1), waidpid and trapping the
>> signal when a child dies without ever succeeding to reap zombies. This
>> means, I will stop and will leave the issue open to anyone who can
>> find a working solution.
>
> The 'zombie reaping' needs to happen in the parent process. This means
> the backend has to care for any processes it starts via fork. And the
> frontend has to care for the backend. You can get a tree view of
> processes via ps f, eg,
>
> ps fx
>
> to show all processed running under you current uid.
>
> [...]
>
>
>> initialization
>>
>>   sa.sa_handler := @handle_sigchld;
>
> Insofar the documentation goes, you should be able to replace this with
>
> sa.sa_handler := SIG_IGN;
>
> this means now direct backend processes will ever be zombified. As the
> backend is written in C, a single
>
> signal(SIGCHLD, SIG_IGN);
>
> will take care of all processes spawned by the backend.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:

> Hi,
>
> For the last days I have been struggling to reap zombies adopted by
> the frontend with only failures.

The frontend doesn't adopt zombies. Only init ever does that. 

> I tried several methods using wait(-1), waidpid and trapping the
> signal when a child dies without ever succeeding to reap zombies. This
> means, I will stop and will leave the issue open to anyone who can
> find a working solution.

The 'zombie reaping' needs to happen in the parent process. This means
the backend has to care for any processes it starts via fork. And the
frontend has to care for the backend. You can get a tree view of
processes via ps f, eg,

ps fx

to show all processed running under you current uid.

[...]


> initialization
>
>   sa.sa_handler := @handle_sigchld;

Insofar the documentation goes, you should be able to replace this with

sa.sa_handler := SIG_IGN;

this means now direct backend processes will ever be zombified. As the
backend is written in C, a single

signal(SIGCHLD, SIG_IGN);

will take care of all processes spawned by the backend.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Tomorrow, I will make it a point to push my multithreaded version of
netman for evaluation. You will see multithreading did not add much
complexity with the benefit of better frontend responsiveness and no
zombies lurking around.

On 03/09/2015, Edward Bartolo  wrote:
> I kept a multithreaded netman version installed on my computer so that
> I would be able to connect to wifi with a couple of button clicks. All
> I can say is, that it doesn't create zombies and it is well behaved.
> What we should do is do away with execl which *replaces* backend
> effectively killing it and letting the new child execute. The backend
> is already using popen to run executables, so we can use that instead
> of the problematic execl. This to make things easier for TThread
> instead of expecting it to behave when we call execl which kills the
> thread controlled by TThread.
>
> I think, TThread may present a simple solution that allows us to keep
> the code effectively as it is without a drastic overhaul.
>
> What I need is to use ps to check for any children owned by netman,
> and the whole application will be almost ready.
>
> ps command: ps xao pid,ppid,comm | grep netman
> Look for any process parented by netman and adjust the frontend
> accordingly and we are almost ready.
>
> Edward.
>
> On 03/09/2015, Steve Litt  wrote:
>> On Thu, 3 Sep 2015 18:24:51 +0100
>> Edward Bartolo  wrote:
>>
>>> I found that the created zombies are owned by root and the frontend
>>> does not run with root privileges. I think, this may be the reason.
>>>
>>> The reason why zombies are created is that we are effectively
>>> replacing backend by what execl calls. We may be able to solve the
>>> issue by allowing the backend to continue running when execl is used
>>> and at the end call wait() if that is possible.
>>
>> Holy cow! Why does anything require execl()? As this whole escapade
>> goes to show, execl() has complication that is not without cost. I'm
>> also not sure why C is needed.
>>
>> I'm thinking your back end could probably be a simple shellscript that
>> interacts with wpa_supplicant and its config file. I'll admit the
>> documentation for wpa_supplicant is ambiguous, contradictory and
>> pathologically incomplete, but I'm pretty sure nothing about this
>> problem domain requires execl(). Just have the back end running, and
>> have the front end communicate with it in a simple and well documented
>> manner of your design.
>>
>> SteveT
>>
>> Steve Litt
>> August 2015 featured book: Troubleshooting: Just the Facts
>> http://www.troubleshooters.com/tjust
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

I kept a multithreaded netman version installed on my computer so that
I would be able to connect to wifi with a couple of button clicks. All
I can say is, that it doesn't create zombies and it is well behaved.
What we should do is do away with execl which *replaces* backend
effectively killing it and letting the new child execute. The backend
is already using popen to run executables, so we can use that instead
of the problematic execl. This to make things easier for TThread
instead of expecting it to behave when we call execl which kills the
thread controlled by TThread.

I think, TThread may present a simple solution that allows us to keep
the code effectively as it is without a drastic overhaul.

What I need is to use ps to check for any children owned by netman,
and the whole application will be almost ready.

ps command: ps xao pid,ppid,comm | grep netman
Look for any process parented by netman and adjust the frontend
accordingly and we are almost ready.

Edward.

On 03/09/2015, Steve Litt  wrote:
> On Thu, 3 Sep 2015 18:24:51 +0100
> Edward Bartolo  wrote:
>
>> I found that the created zombies are owned by root and the frontend
>> does not run with root privileges. I think, this may be the reason.
>>
>> The reason why zombies are created is that we are effectively
>> replacing backend by what execl calls. We may be able to solve the
>> issue by allowing the backend to continue running when execl is used
>> and at the end call wait() if that is possible.
>
> Holy cow! Why does anything require execl()? As this whole escapade
> goes to show, execl() has complication that is not without cost. I'm
> also not sure why C is needed.
>
> I'm thinking your back end could probably be a simple shellscript that
> interacts with wpa_supplicant and its config file. I'll admit the
> documentation for wpa_supplicant is ambiguous, contradictory and
> pathologically incomplete, but I'm pretty sure nothing about this
> problem domain requires execl(). Just have the back end running, and
> have the front end communicate with it in a simple and well documented
> manner of your design.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Steve Litt]

On Thu, 3 Sep 2015 18:24:51 +0100
Edward Bartolo  wrote:

> I found that the created zombies are owned by root and the frontend
> does not run with root privileges. I think, this may be the reason.
> 
> The reason why zombies are created is that we are effectively
> replacing backend by what execl calls. We may be able to solve the
> issue by allowing the backend to continue running when execl is used
> and at the end call wait() if that is possible.

Holy cow! Why does anything require execl()? As this whole escapade
goes to show, execl() has complication that is not without cost. I'm
also not sure why C is needed.

I'm thinking your back end could probably be a simple shellscript that
interacts with wpa_supplicant and its config file. I'll admit the
documentation for wpa_supplicant is ambiguous, contradictory and
pathologically incomplete, but I'm pretty sure nothing about this
problem domain requires execl(). Just have the back end running, and
have the front end communicate with it in a simple and well documented
manner of your design.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[KatolaZ]

On Thu, Sep 03, 2015 at 06:53:46PM +0100, KatolaZ wrote:

[cut]

> 
> OK, I admit it might had been a tad too cryptic, but my intentions
> were good. What I mean is that the parent has to set a handler for
> SIGCHLD, and the handler has to call wait() [or waitpid(-1, &status)]
> to reap the dead child. The handler must be set *before* any of the
> children is ever spawn, otherwise there is still a concrete chance to
> create zombies.
> 
> If your parent process handles SIGCHLD correctly, you can also force
> reaping by sending it a SIGCHLD with the kill command.
> 

To make things more clear, here is a minimal example:

  http://www.linuxprogrammingblog.com/code-examples/SIGCHLD-handler

Beware that in this case the children do nothing (they just exit
immediately), and the final while(sleep(1)) is not required.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[KatolaZ]

On Thu, Sep 03, 2015 at 06:36:39PM +0100, KatolaZ wrote:

[cut]

> 
> Sorry guys, I didn't get through the whole thread, but I wanted to say
> just one obvious thing: if your program works correctly, then it is
> *very* difficult (if not impossible) to create and leave zombies
> around. If the program that fork()s does call wait() properly, no
> zombies can remain anywhere. A zombie is just a process which has died
> and is waiting there for its parent to call the damn wait(). 
> 
> If your code leaves zombies, then it is not working properly, and you
> should fix it before moving on.
> 

OK, I admit it might had been a tad too cryptic, but my intentions
were good. What I mean is that the parent has to set a handler for
SIGCHLD, and the handler has to call wait() [or waitpid(-1, &status)]
to reap the dead child. The handler must be set *before* any of the
children is ever spawn, otherwise there is still a concrete chance to
create zombies.

If your parent process handles SIGCHLD correctly, you can also force
reaping by sending it a SIGCHLD with the kill command.

My2Cents

KatolaZ


-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[KatolaZ]

On Thu, Sep 03, 2015 at 06:24:51PM +0100, Edward Bartolo wrote:
> I found that the created zombies are owned by root and the frontend
> does not run with root privileges. I think, this may be the reason.
> 
> The reason why zombies are created is that we are effectively
> replacing backend by what execl calls. We may be able to solve the
> issue by allowing the backend to continue running when execl is used
> and at the end call wait() if that is possible.
> 

Sorry guys, I didn't get through the whole thread, but I wanted to say
just one obvious thing: if your program works correctly, then it is
*very* difficult (if not impossible) to create and leave zombies
around. If the program that fork()s does call wait() properly, no
zombies can remain anywhere. A zombie is just a process which has died
and is waiting there for its parent to call the damn wait(). 

If your code leaves zombies, then it is not working properly, and you
should fix it before moving on.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Laurent Bercot]

On 03/09/2015 18:35, Steve Litt wrote:

I'd figure out how to stop those zombies from happening in the first
place. It's pretty hard to create a zombie: I think you have to
doublefork and then terminate.


 Nope, a zombie is actually very easy to create:
 - have a process parent that spawns a child and stays alive
 - have the child die first, and the parent not reap it.
That's it. A dead child is a zombie until the parent acknowledges its
death, and if the parent is failing its duties, the zombie will remain,
an empty soulless shell spawned inconsiderately with no love or
regards for consequences that will haunt the system forever.

 ...not quite forever. If the parent dies, the child process' paternity
will be reassigned to PID1, and PID1 will receive a SIGCHLD. Basically
every PID1 program correctly handles that and reaps every zombie it gets,
even if it's not the one that fathered it.

 But when the parent is a daemon, it's not supposed to die, so counting
on PID1 to do the dirty work is obviously not a solution, and it has to
reap children.

 Edward's problem is that his "backend" process is spawning children and
not reaping them. It has nothing to do with the frontend. To make sure
what process the zombies are children of, use the "f" option to ps, or
the pstree utility.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

I found that the created zombies are owned by root and the frontend
does not run with root privileges. I think, this may be the reason.

The reason why zombies are created is that we are effectively
replacing backend by what execl calls. We may be able to solve the
issue by allowing the backend to continue running when execl is used
and at the end call wait() if that is possible.

Edward

On 03/09/2015, Steve Litt  wrote:
> On Thu, 3 Sep 2015 07:38:13 +0100
> Edward Bartolo  wrote:
>
> I'd figure out how to stop those zombies from happening in the first
> place. It's pretty hard to create a zombie: I think you have to
> doublefork and then terminate. In that case, if you're using a good
> init system, I believe you can send PID1 a SIGCHLD, and PID1 will reap
> zombies. I know that's how suckless-init works. I suggest you download
> Suckless-Init and look at its source: It's only 83 non-blank lines.
>
> But again, I think the question "how do I reap zombies" is a little
> like "how do I sweep up broken glass", when you're dropping and
> breaking 3 glasses every day. The better question is "why am I dropping
> these glasses?"
>
> SteveT
>
>
>> I am trying to reap zombies. The "while(fpwaitpid" pascal code is
>> freezing my application.
>>
>> *
>> procedure handle_sigchld(sig: longint; info: psiginfo; context:
>> psigcontext); cdecl;
>> var
>>   Status: cint;
>>   a_pid: pid_t;
>> begin
>>   Status := 0;
>>   a_pid := -1;
>>
>> // This is freezing my application
>>   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
>>   begin
>> backend_lives := backend_lives + 1;
>> showmessage('hi strunz!!!');
>>   end;
>> end;
>>
>>
>> var sa: sigactionrec;
>>
>> initialization
>>   sa.sa_handler := @handle_sigchld;
>>   fpsigemptyset(&sa.sa_mask);
>>
>>   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
>>   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
>>   begin
>> // do nothing
>>   end;
>> **
>>
>> Any ideas?
>>
>>
>> Edward
>>
>>
>>
>> On 02/09/2015, Steve Litt  wrote:
>> > Personally, I'd go way out of my way never to multithread unless
>> > there were a huge reason to do so. Your app does such a small, quick
>> > job that there's no reason.
>> >
>> > You mentioned the front and back end communicating with each other,
>> > and everyone mentioned fifos. I agree. And if there's a reason for
>> > one program to tell the other that info's ready for it, that's what
>> > SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for.
>> >
>> > SteveT
>> >
>> > Steve Litt
>> > August 2015 featured book: Troubleshooting: Just the Facts
>> > http://www.troubleshooters.com/tjust
>> >
>> >
>> > On Wed, 2 Sep 2015 19:45:08 +0100
>> > Edward Bartolo  wrote:
>> >
>> >> What about multithreading? Should I do away with it and let the
>> >> frontend monitor for zombies to call waitpid?
>> >>
>> >> Edward
>> >>
>> >> On 02/09/2015, Steve Litt  wrote:
>> >> > On Wed, 2 Sep 2015 11:47:34 +0100
>> >> > Edward Bartolo  wrote:
>> >> >
>> >> >> Hi all,
>> >> >>
>> >> >> I think, I found an alternative to multithreading in netman.
>> >> >> This is using interprocess communication, although what I have
>> >> >> in mind may not be proper interprocess communication.
>> >> >>
>> >> >> The idea is this: the backend would be converted into some sort
>> >> >> of a daemon exporting one function and importing another one.
>> >> >> The frontend would use the exported function from the backend
>> >> >> to send it commands. The backend would do the same thing with
>> >> >> the exported function from the frontend:
>> >> >>
>> >> >> Visually, this is as follows:
>> >> >>
>> >> >> Frontend -->> Backend
>> >> >> Frontend <<-- Backend
>> >> >>
>> >> >> In my humble opinion, this may help getting rid of having to use
>> >> >> multithreading to avoid temporary frontend deadlocks. It also
>> >> >> solves the issue with zombies being created, and would permit me
>> >> >> create a responsive application but using the KISS principle.
>> >> >
>> >> > I like it. A lot!
>> >> >
>> >> > IMHO the front end should do nothing but display ESSIDs with
>> >> > strength and encryption, letting you click on the one you want or
>> >> > right click and say "turn off" to turn it off.
>> >> >
>> >> > If you've already dealt with that ESSID, the back end has the
>> >> > password and uses it to join that ESSID. If the back end hasn't
>> >> > dealt with it, it sends the front end a message saying "get me
>> >> > the password", the front end queries the user for the password,
>> >> > and the front end sends it back to the back end. Assuming one
>> >> > user, this doesn't even have to be stateful, but if it has to be
>> >> > stateful, there are a million ways to do it.
>> >> >
>> >> > I like it!
>> >> >
>> >> > SteveT
>> >> >
>> >> > Steve Litt
>> >> > August 2015 featured book: Troubleshooting: Just the Facts
>> >> > 

Re: [DNG] Doing away with multi-threading in my project (netman)

[Steve Litt]

On Thu, 3 Sep 2015 07:38:13 +0100
Edward Bartolo  wrote:

I'd figure out how to stop those zombies from happening in the first
place. It's pretty hard to create a zombie: I think you have to
doublefork and then terminate. In that case, if you're using a good
init system, I believe you can send PID1 a SIGCHLD, and PID1 will reap
zombies. I know that's how suckless-init works. I suggest you download
Suckless-Init and look at its source: It's only 83 non-blank lines.

But again, I think the question "how do I reap zombies" is a little
like "how do I sweep up broken glass", when you're dropping and
breaking 3 glasses every day. The better question is "why am I dropping
these glasses?"

SteveT


> I am trying to reap zombies. The "while(fpwaitpid" pascal code is
> freezing my application.
> 
> *
> procedure handle_sigchld(sig: longint; info: psiginfo; context:
> psigcontext); cdecl;
> var
>   Status: cint;
>   a_pid: pid_t;
> begin
>   Status := 0;
>   a_pid := -1;
> 
> // This is freezing my application
>   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
>   begin
> backend_lives := backend_lives + 1;
> showmessage('hi strunz!!!');
>   end;
> end;
> 
> 
> var sa: sigactionrec;
> 
> initialization
>   sa.sa_handler := @handle_sigchld;
>   fpsigemptyset(&sa.sa_mask);
> 
>   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
>   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
>   begin
> // do nothing
>   end;
> **
> 
> Any ideas?
> 
> 
> Edward
> 
> 
> 
> On 02/09/2015, Steve Litt  wrote:
> > Personally, I'd go way out of my way never to multithread unless
> > there were a huge reason to do so. Your app does such a small, quick
> > job that there's no reason.
> >
> > You mentioned the front and back end communicating with each other,
> > and everyone mentioned fifos. I agree. And if there's a reason for
> > one program to tell the other that info's ready for it, that's what
> > SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for.
> >
> > SteveT
> >
> > Steve Litt
> > August 2015 featured book: Troubleshooting: Just the Facts
> > http://www.troubleshooters.com/tjust
> >
> >
> > On Wed, 2 Sep 2015 19:45:08 +0100
> > Edward Bartolo  wrote:
> >
> >> What about multithreading? Should I do away with it and let the
> >> frontend monitor for zombies to call waitpid?
> >>
> >> Edward
> >>
> >> On 02/09/2015, Steve Litt  wrote:
> >> > On Wed, 2 Sep 2015 11:47:34 +0100
> >> > Edward Bartolo  wrote:
> >> >
> >> >> Hi all,
> >> >>
> >> >> I think, I found an alternative to multithreading in netman.
> >> >> This is using interprocess communication, although what I have
> >> >> in mind may not be proper interprocess communication.
> >> >>
> >> >> The idea is this: the backend would be converted into some sort
> >> >> of a daemon exporting one function and importing another one.
> >> >> The frontend would use the exported function from the backend
> >> >> to send it commands. The backend would do the same thing with
> >> >> the exported function from the frontend:
> >> >>
> >> >> Visually, this is as follows:
> >> >>
> >> >> Frontend -->> Backend
> >> >> Frontend <<-- Backend
> >> >>
> >> >> In my humble opinion, this may help getting rid of having to use
> >> >> multithreading to avoid temporary frontend deadlocks. It also
> >> >> solves the issue with zombies being created, and would permit me
> >> >> create a responsive application but using the KISS principle.
> >> >
> >> > I like it. A lot!
> >> >
> >> > IMHO the front end should do nothing but display ESSIDs with
> >> > strength and encryption, letting you click on the one you want or
> >> > right click and say "turn off" to turn it off.
> >> >
> >> > If you've already dealt with that ESSID, the back end has the
> >> > password and uses it to join that ESSID. If the back end hasn't
> >> > dealt with it, it sends the front end a message saying "get me
> >> > the password", the front end queries the user for the password,
> >> > and the front end sends it back to the back end. Assuming one
> >> > user, this doesn't even have to be stateful, but if it has to be
> >> > stateful, there are a million ways to do it.
> >> >
> >> > I like it!
> >> >
> >> > SteveT
> >> >
> >> > Steve Litt
> >> > August 2015 featured book: Troubleshooting: Just the Facts
> >> > http://www.troubleshooters.com/tjust
> >> > ___
> >> > Dng mailing list
> >> > Dng@lists.dyne.org
> >> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >> >
> >
> >
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >




SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng m

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Hi,

For the last days I have been struggling to reap zombies adopted by
the frontend with only failures. I tried several methods using
wait(-1), waidpid and trapping the signal when a child dies without
ever succeeding to reap zombies. This means, I will stop and will
leave the issue open to anyone who can find a working solution. With
zombies or not, the application works. So I will continue with real
development instead of fighting a seeming impossible battle.

The pascal code that I used to reap zombies:
==
procedure handle_sigchld(sig: longint; info: psiginfo; context:
psigcontext); cdecl;
var
  Status: cint;
  a_pid: pid_t;
begin
  Status := 0;
  a_pid := -1;
{
  SIGCHLD
  CLD_EXITEDchild has exited
  CLD_KILLEDchild was killed
  CLD_DUMPEDchild terminated abnormally
  CLD_TRAPPED   traced child has trapped
  CLD_STOPPED   child has stopped
  CLD_CONTINUED stopped child had continued
}

  //CLD_EXITED = 1; CLD_KILLED = 2
  if info^.si_code = 2 then
  begin
backend_lives := backend_lives + 1;
//fpwaitpid(a_pid, Status, WNOHANG);
//fpwaitpid(info^._sifields._sigchld._pid,
info^._sifields._sigchld._status, WNOHANG);
//fpwait(info^._sifields._sigchld._pid); //,
info^._sifields._sigchld._status, WNOHANG);
//info^._sifields._sigchld._pid:=;
//while fpwait(a_pid) > 0 do;

s := s + inttostr(info^.si_code) + '.';

{  while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
  begin
backend_lives := backend_lives + 1;
   end; }
  end;


end;


var sa: sigactionrec;

initialization

  sa.sa_handler := @handle_sigchld;
  fpsigemptyset(&sa.sa_mask);

  sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
  if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
  begin
// do nothing
  end;

==


Edward

On 03/09/2015, poitr pogo  wrote:
> hmm, I do wifi connect in bash/xterm
>
> one shot
> sudo vi /etc/network/interfaces
> add
>
> source /etc/network/interfaces.d/*.cfg
>
> if not already there
>
> make sure /etc/network/interfaces.d folder exists
>
> later, check what is available
>
> sudo iwlist wlan0 scanning |grep -e ESSID -e Quality
> Quality=70/70  Signal level=-40 dBm
> ESSID:"apn 1"
>
> If never used one before
>
> sudo /etc/network/interfaces.d/apn_1.cfg
>
> iface apn_1 inet dhcp
> wpa-ssid "apn 1"
> wpa-psk mypass1234
>
>
> from now on to connect to "apn 1"  I just do
>
> sudo ifup wlan0=apn_1
>
>
> --
>
> regards
> piotr
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[poitr pogo]

hmm, I do wifi connect in bash/xterm

one shot
sudo vi /etc/network/interfaces
add

source /etc/network/interfaces.d/*.cfg

if not already there

make sure /etc/network/interfaces.d folder exists

later, check what is available

sudo iwlist wlan0 scanning |grep -e ESSID -e Quality
Quality=70/70  Signal level=-40 dBm
ESSID:"apn 1"

If never used one before

sudo /etc/network/interfaces.d/apn_1.cfg

iface apn_1 inet dhcp
wpa-ssid "apn 1"
wpa-psk mypass1234


from now on to connect to "apn 1"  I just do

sudo ifup wlan0=apn_1


--

regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:
> I am trying to reap zombies. The "while(fpwaitpid" pascal code is
> freezing my application.
>
> *
> procedure handle_sigchld(sig: longint; info: psiginfo; context:
> psigcontext); cdecl;
> var
>   Status: cint;
>   a_pid: pid_t;
> begin
>   Status := 0;
>   a_pid := -1;
>
> // This is freezing my application
>   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
>   begin
> backend_lives := backend_lives + 1;
> showmessage('hi strunz!!!');
>   end;
> end;
>
>
> var sa: sigactionrec;
>
> initialization
>   sa.sa_handler := @handle_sigchld;
>   fpsigemptyset(&sa.sa_mask);
>
>   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
>   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
>   begin
> // do nothing
>   end;
> **
>
> Any ideas?

As was already mentioned: The second argument to fpwaitpid must be a
pointer. As opposed to what was already mentioned, the loop condition is
generally correct: The loop must terminate if the return value is either
-1 (some kind of error occurred) or 0 (nothing more to do right now).

Caveat: The signal handler is asynchronously invoked by the kernel when
a SIGCHLD is posted and it will interrupt whatever else the application
was doing at the moment. This means it's as if it was running in a
separate thread (except even more complicated).

According to

http://www.freepascal.org/docs-html/rtl/baseunix/fpsigaction.html

Sa_Handler may be SIG_DFL for the default action or SIG_IGN to
ignore the signal.

For as long as you aren't using the exit status, using SIG_IGN instead
of a signal handler is to be preferred as the kernel will then just not
create zombies.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[tilt!]

Sorry,

come to think about it, simply return if rv is -1,
because that means there are no un-waited children left.

You should definately first fix the pcint Status issue,
because if you give an invalid argument ot waitpid, it
returns -1 and sets errno to EINVAL.

while true
rv := waitpid(-1, Status, WNOHANG);

if rv=-1
   if fpGetErrno <> ECHILD the
  report "ERROR: unexpected error: " fpGetErrno
   return;
else if rv<>0
   report "DEBUG: pid " rv " exited with status " Status
   continue;
end; {* while true *}

Best regards,
T.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[tilt!]

Hi Edward,

AFAIK Status must be a pointer, because fpwaitpid will write
information into that status.

Also, you should check the return value of fpwaitpid():

 0 : nothing has happened
 -1: an error occurred, check fgGetErrno
 other: the pid of a child where something happened

so like (pseudocode):

cint rv;
pcint Status;

while true
   rv := waitpid(-1, Status, WNOHANG);

   if rv=-1
  {* an error occured, report fpGetErrno *}
  return;
   else if rv<>0
  {* rv is the pid that was reaped,
 you could report rv and Status now *}
  return;
   else
  {* nothing has happened, resume waiting *}
  continue;
end;

If that doesn't help, check that this way of handling
children does not conflict with some option you have
set for the child TProcess.

Best regards,
T.


On 09/03/2015 08:38 AM, Edward Bartolo wrote:

I am trying to reap zombies. The "while(fpwaitpid" pascal code is
freezing my application.

*
procedure handle_sigchld(sig: longint; info: psiginfo; context:
psigcontext); cdecl;
var
   Status: cint;
   a_pid: pid_t;
begin
   Status := 0;
   a_pid := -1;

// This is freezing my application
   while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
   begin
 backend_lives := backend_lives + 1;
 showmessage('hi strunz!!!');
   end;
end;


var sa: sigactionrec;

initialization
   sa.sa_handler := @handle_sigchld;
   fpsigemptyset(&sa.sa_mask);

   sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
   if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
   begin
 // do nothing
   end;
**

Any ideas?


Edward



On 02/09/2015, Steve Litt  wrote:

Personally, I'd go way out of my way never to multithread unless
there were a huge reason to do so. Your app does such a small, quick
job that there's no reason.

You mentioned the front and back end communicating with each other, and
everyone mentioned fifos. I agree. And if there's a reason for one
program to tell the other that info's ready for it, that's what SIGUSR1
and SIGUSR2 are for. Or at least what *I* use them for.

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust


On Wed, 2 Sep 2015 19:45:08 +0100
Edward Bartolo  wrote:


What about multithreading? Should I do away with it and let the
frontend monitor for zombies to call waitpid?

Edward

On 02/09/2015, Steve Litt  wrote:

On Wed, 2 Sep 2015 11:47:34 +0100
Edward Bartolo  wrote:


Hi all,

I think, I found an alternative to multithreading in netman. This
is using interprocess communication, although what I have in mind
may not be proper interprocess communication.

The idea is this: the backend would be converted into some sort of
a daemon exporting one function and importing another one. The
frontend would use the exported function from the backend to send
it commands. The backend would do the same thing with the exported
function from the frontend:

Visually, this is as follows:

Frontend -->> Backend
Frontend <<-- Backend

In my humble opinion, this may help getting rid of having to use
multithreading to avoid temporary frontend deadlocks. It also
solves the issue with zombies being created, and would permit me
create a responsive application but using the KISS principle.


I like it. A lot!

IMHO the front end should do nothing but display ESSIDs with
strength and encryption, letting you click on the one you want or
right click and say "turn off" to turn it off.

If you've already dealt with that ESSID, the back end has the
password and uses it to join that ESSID. If the back end hasn't
dealt with it, it sends the front end a message saying "get me the
password", the front end queries the user for the password, and the
front end sends it back to the back end. Assuming one user, this
doesn't even have to be stateful, but if it has to be stateful,
there are a million ways to do it.

I like it!

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

I am trying to reap zombies. The "while(fpwaitpid" pascal code is
freezing my application.

*
procedure handle_sigchld(sig: longint; info: psiginfo; context:
psigcontext); cdecl;
var
  Status: cint;
  a_pid: pid_t;
begin
  Status := 0;
  a_pid := -1;

// This is freezing my application
  while (fpwaitpid(a_pid, Status, WNOHANG) > 0) do
  begin
backend_lives := backend_lives + 1;
showmessage('hi strunz!!!');
  end;
end;


var sa: sigactionrec;

initialization
  sa.sa_handler := @handle_sigchld;
  fpsigemptyset(&sa.sa_mask);

  sa.sa_flags := (SA_RESTART or SA_NOCLDSTOP);
  if (fpsigaction(SIGCHLD, @sa, nil) = -1) then
  begin
// do nothing
  end;
**

Any ideas?


Edward



On 02/09/2015, Steve Litt  wrote:
> Personally, I'd go way out of my way never to multithread unless
> there were a huge reason to do so. Your app does such a small, quick
> job that there's no reason.
>
> You mentioned the front and back end communicating with each other, and
> everyone mentioned fifos. I agree. And if there's a reason for one
> program to tell the other that info's ready for it, that's what SIGUSR1
> and SIGUSR2 are for. Or at least what *I* use them for.
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
>
>
> On Wed, 2 Sep 2015 19:45:08 +0100
> Edward Bartolo  wrote:
>
>> What about multithreading? Should I do away with it and let the
>> frontend monitor for zombies to call waitpid?
>>
>> Edward
>>
>> On 02/09/2015, Steve Litt  wrote:
>> > On Wed, 2 Sep 2015 11:47:34 +0100
>> > Edward Bartolo  wrote:
>> >
>> >> Hi all,
>> >>
>> >> I think, I found an alternative to multithreading in netman. This
>> >> is using interprocess communication, although what I have in mind
>> >> may not be proper interprocess communication.
>> >>
>> >> The idea is this: the backend would be converted into some sort of
>> >> a daemon exporting one function and importing another one. The
>> >> frontend would use the exported function from the backend to send
>> >> it commands. The backend would do the same thing with the exported
>> >> function from the frontend:
>> >>
>> >> Visually, this is as follows:
>> >>
>> >> Frontend -->> Backend
>> >> Frontend <<-- Backend
>> >>
>> >> In my humble opinion, this may help getting rid of having to use
>> >> multithreading to avoid temporary frontend deadlocks. It also
>> >> solves the issue with zombies being created, and would permit me
>> >> create a responsive application but using the KISS principle.
>> >
>> > I like it. A lot!
>> >
>> > IMHO the front end should do nothing but display ESSIDs with
>> > strength and encryption, letting you click on the one you want or
>> > right click and say "turn off" to turn it off.
>> >
>> > If you've already dealt with that ESSID, the back end has the
>> > password and uses it to join that ESSID. If the back end hasn't
>> > dealt with it, it sends the front end a message saying "get me the
>> > password", the front end queries the user for the password, and the
>> > front end sends it back to the back end. Assuming one user, this
>> > doesn't even have to be stateful, but if it has to be stateful,
>> > there are a million ways to do it.
>> >
>> > I like it!
>> >
>> > SteveT
>> >
>> > Steve Litt
>> > August 2015 featured book: Troubleshooting: Just the Facts
>> > http://www.troubleshooters.com/tjust
>> > ___
>> > Dng mailing list
>> > Dng@lists.dyne.org
>> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>> >
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[tilt!]

On 09/02/2015 10:27 PM, Steve Litt wrote:
> Personally, I'd go way out of my way never to multithread unless
> there were a huge reason to do so. Your app does such a small, quick
> job that there's no reason.
>
> You mentioned the front and back end communicating with each other,
> and everyone mentioned fifos. I agree. And if there's a reason for
> one program to tell the other that info's ready for it, that's what
> SIGUSR1 and SIGUSR2 are for. Or at least what *I* use them for.

Yeah ok, let's do this :)

But where's the most current code? :-D I lost sight of it at some point.

Best regards,
T.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Steve Litt]

Personally, I'd go way out of my way never to multithread unless
there were a huge reason to do so. Your app does such a small, quick
job that there's no reason.

You mentioned the front and back end communicating with each other, and
everyone mentioned fifos. I agree. And if there's a reason for one
program to tell the other that info's ready for it, that's what SIGUSR1
and SIGUSR2 are for. Or at least what *I* use them for.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust


On Wed, 2 Sep 2015 19:45:08 +0100
Edward Bartolo  wrote:

> What about multithreading? Should I do away with it and let the
> frontend monitor for zombies to call waitpid?
> 
> Edward
> 
> On 02/09/2015, Steve Litt  wrote:
> > On Wed, 2 Sep 2015 11:47:34 +0100
> > Edward Bartolo  wrote:
> >
> >> Hi all,
> >>
> >> I think, I found an alternative to multithreading in netman. This
> >> is using interprocess communication, although what I have in mind
> >> may not be proper interprocess communication.
> >>
> >> The idea is this: the backend would be converted into some sort of
> >> a daemon exporting one function and importing another one. The
> >> frontend would use the exported function from the backend to send
> >> it commands. The backend would do the same thing with the exported
> >> function from the frontend:
> >>
> >> Visually, this is as follows:
> >>
> >> Frontend -->> Backend
> >> Frontend <<-- Backend
> >>
> >> In my humble opinion, this may help getting rid of having to use
> >> multithreading to avoid temporary frontend deadlocks. It also
> >> solves the issue with zombies being created, and would permit me
> >> create a responsive application but using the KISS principle.
> >
> > I like it. A lot!
> >
> > IMHO the front end should do nothing but display ESSIDs with
> > strength and encryption, letting you click on the one you want or
> > right click and say "turn off" to turn it off.
> >
> > If you've already dealt with that ESSID, the back end has the
> > password and uses it to join that ESSID. If the back end hasn't
> > dealt with it, it sends the front end a message saying "get me the
> > password", the front end queries the user for the password, and the
> > front end sends it back to the back end. Assuming one user, this
> > doesn't even have to be stateful, but if it has to be stateful,
> > there are a million ways to do it.
> >
> > I like it!
> >
> > SteveT
> >
> > Steve Litt
> > August 2015 featured book: Troubleshooting: Just the Facts
> > http://www.troubleshooters.com/tjust
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

What about multithreading? Should I do away with it and let the
frontend monitor for zombies to call waitpid?

Edward

On 02/09/2015, Steve Litt  wrote:
> On Wed, 2 Sep 2015 11:47:34 +0100
> Edward Bartolo  wrote:
>
>> Hi all,
>>
>> I think, I found an alternative to multithreading in netman. This is
>> using interprocess communication, although what I have in mind may not
>> be proper interprocess communication.
>>
>> The idea is this: the backend would be converted into some sort of a
>> daemon exporting one function and importing another one. The frontend
>> would use the exported function from the backend to send it commands.
>> The backend would do the same thing with the exported function from
>> the frontend:
>>
>> Visually, this is as follows:
>>
>> Frontend -->> Backend
>> Frontend <<-- Backend
>>
>> In my humble opinion, this may help getting rid of having to use
>> multithreading to avoid temporary frontend deadlocks. It also solves
>> the issue with zombies being created, and would permit me create a
>> responsive application but using the KISS principle.
>
> I like it. A lot!
>
> IMHO the front end should do nothing but display ESSIDs with strength
> and encryption, letting you click on the one you want or right click
> and say "turn off" to turn it off.
>
> If you've already dealt with that ESSID, the back end has the password
> and uses it to join that ESSID. If the back end hasn't dealt with it,
> it sends the front end a message saying "get me the password", the
> front end queries the user for the password, and the front end sends it
> back to the back end. Assuming one user, this doesn't even have to be
> stateful, but if it has to be stateful, there are a million ways to do
> it.
>
> I like it!
>
> SteveT
>
> Steve Litt
> August 2015 featured book: Troubleshooting: Just the Facts
> http://www.troubleshooters.com/tjust
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Steve Litt]

On Wed, 2 Sep 2015 11:47:34 +0100
Edward Bartolo  wrote:

> Hi all,
> 
> I think, I found an alternative to multithreading in netman. This is
> using interprocess communication, although what I have in mind may not
> be proper interprocess communication.
> 
> The idea is this: the backend would be converted into some sort of a
> daemon exporting one function and importing another one. The frontend
> would use the exported function from the backend to send it commands.
> The backend would do the same thing with the exported function from
> the frontend:
> 
> Visually, this is as follows:
> 
> Frontend -->> Backend
> Frontend <<-- Backend
> 
> In my humble opinion, this may help getting rid of having to use
> multithreading to avoid temporary frontend deadlocks. It also solves
> the issue with zombies being created, and would permit me create a
> responsive application but using the KISS principle.

I like it. A lot!

IMHO the front end should do nothing but display ESSIDs with strength
and encryption, letting you click on the one you want or right click
and say "turn off" to turn it off.

If you've already dealt with that ESSID, the back end has the password
and uses it to join that ESSID. If the back end hasn't dealt with it,
it sends the front end a message saying "get me the password", the
front end queries the user for the password, and the front end sends it
back to the back end. Assuming one user, this doesn't even have to be
stateful, but if it has to be stateful, there are a million ways to do
it.

I like it!

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

I found this code in gensigset.inc and signals.inc fpc source library.
Is this what we are talking about?

function FPSigaction(
  sig: cint;
  act: psigactionrec;
  oact: psigactionrec
):cint;

function fpsigemptyset(var nset : tsigset):cint;
var i :longint;
Begin
  for i:=0 to wordsinsigset-1 DO nset[i]:=0;
  fpsigemptyset:=0;
End;

And:

type
  sigset_t = array[0..wordsinsigset-1] of cuLong;
  tsigset  = sigset_t;
  sigset   = sigset_t;
  psigset  = ^tsigset;

  psiginfo = ^tsiginfo;
  tsiginfo = record
   si_signo : longint;
   si_errno : longint;
   si_code : longint;
   _sifields : record
   case longint of
  0 : ( _pad : array[0..(SI_PAD_SIZE)-1] of longint );
  1 : ( _kill : record
   _pid : pid_t;
   _uid : uid_t;
end );
  2 : ( _timer : record
   _timer1 : dword;
   _timer2 : dword;
end );
  3 : ( _rt : record
   _pid : pid_t;
   _uid : uid_t;
   _sigval : pointer;
end );
  4 : ( _sigchld : record
   _pid : pid_t;
   _uid : uid_t;
   _status : longint;
   _utime : clock_t;
   _stime : clock_t;
end );
  5 : ( _sigfault : record
   _addr : pointer;
end );
  6 : ( _sigpoll : record
   _band : longint;
   _fd : longint;
end );
   end;
end;




On 02/09/2015, Edward Bartolo  wrote:
> Quote: "This means the GUI/ frontend
> either needs to handle SIGCHLD in order to get notified when a child
> process terminates so that a suitable wait call (which doubtlessly exists in
> the
> Free Pascal libraries) can be used to get rid of the zombie without
> having to wait for it or (the by far most simple solution), it (the GUI)
> needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
> won't even be created."
>
> Aha, that gave me an idea, thanks for that. I can use the signal of
> the arrival of a new zombie as the time at which to re-enable grayed
> out buttons.
>
> The benefit of all this: very little changes to code and no
> multi-threading complications.
>
> Thanks. :D
>
> On 02/09/2015, Rainer Weikusat  wrote:
>> Edward Bartolo  writes:
>>
>> [...]
>>
>>> The idea is this: the backend would be converted into some sort of a
>>> daemon exporting one function and importing another one. The frontend
>>> would use the exported function from the backend to send it commands.
>>> The backend would do the same thing with the exported function from
>>> the frontend:
>>>
>>> Visually, this is as follows:
>>>
>>> Frontend -->> Backend
>>> Frontend <<-- Backend
>>
>> This is not possible because functions can't be 'exported' in this way
>> (OTOH, the whole backend - frontend split is pretty pointless, anyway
>> ...)
>>
>>> In my humble opinion, this may help getting rid of having to use
>>> multithreading to avoid temporary frontend deadlocks.
>>
>> As I already explained to you quite some times: There is no such
>> need. You just have to stop fighting the API for dealing with deceased
>> subprocesses and start using it instead. This means the GUI/ frontend
>> either needs to handle SIGCHLD in order to get notified when a child
>> process terminates so that a suitable wait call (which doubtlessly exists
>> in
>> the
>> Free Pascal libraries) can be used to get rid of the zombie without
>> having to wait for it or (the by far most simple solution), it (the GUI)
>> needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
>> won't even be created.
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Quote: "This means the GUI/ frontend
either needs to handle SIGCHLD in order to get notified when a child
process terminates so that a suitable wait call (which doubtlessly exists in the
Free Pascal libraries) can be used to get rid of the zombie without
having to wait for it or (the by far most simple solution), it (the GUI)
needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
won't even be created."

Aha, that gave me an idea, thanks for that. I can use the signal of
the arrival of a new zombie as the time at which to re-enable grayed
out buttons.

The benefit of all this: very little changes to code and no
multi-threading complications.

Thanks. :D

On 02/09/2015, Rainer Weikusat  wrote:
> Edward Bartolo  writes:
>
> [...]
>
>> The idea is this: the backend would be converted into some sort of a
>> daemon exporting one function and importing another one. The frontend
>> would use the exported function from the backend to send it commands.
>> The backend would do the same thing with the exported function from
>> the frontend:
>>
>> Visually, this is as follows:
>>
>> Frontend -->> Backend
>> Frontend <<-- Backend
>
> This is not possible because functions can't be 'exported' in this way
> (OTOH, the whole backend - frontend split is pretty pointless, anyway
> ...)
>
>> In my humble opinion, this may help getting rid of having to use
>> multithreading to avoid temporary frontend deadlocks.
>
> As I already explained to you quite some times: There is no such
> need. You just have to stop fighting the API for dealing with deceased
> subprocesses and start using it instead. This means the GUI/ frontend
> either needs to handle SIGCHLD in order to get notified when a child
> process terminates so that a suitable wait call (which doubtlessly exists in
> the
> Free Pascal libraries) can be used to get rid of the zombie without
> having to wait for it or (the by far most simple solution), it (the GUI)
> needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
> won't even be created.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Rainer Weikusat]

Edward Bartolo  writes:

[...]

> The idea is this: the backend would be converted into some sort of a
> daemon exporting one function and importing another one. The frontend
> would use the exported function from the backend to send it commands.
> The backend would do the same thing with the exported function from
> the frontend:
>
> Visually, this is as follows:
>
> Frontend -->> Backend
> Frontend <<-- Backend

This is not possible because functions can't be 'exported' in this way
(OTOH, the whole backend - frontend split is pretty pointless, anyway
...) 

> In my humble opinion, this may help getting rid of having to use
> multithreading to avoid temporary frontend deadlocks.

As I already explained to you quite some times: There is no such
need. You just have to stop fighting the API for dealing with deceased
subprocesses and start using it instead. This means the GUI/ frontend
either needs to handle SIGCHLD in order to get notified when a child
process terminates so that a suitable wait call (which doubtlessly exists in the
Free Pascal libraries) can be used to get rid of the zombie without
having to wait for it or (the by far most simple solution), it (the GUI)
needs to set the disposition of SIGCHLD to SIG_IGN because then, zombies
won't even be created.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Hi,

Thanks for the reply. If Unix Domain Sockets can do the job nicely,
why not? However, I will wait for other replies for their opinion.

Thanks.

On 02/09/2015, dr.kl...@gmx.at  wrote:
> Am Mittwoch, 2. September 2015 schrieb Edward Bartolo:
>> Hi all,
>>
>> I think, I found an alternative to multithreading in netman. This is
>> using interprocess communication, although what I have in mind may not
>> be proper interprocess communication.
>>
>> The idea is this: the backend would be converted into some sort of a
>> daemon exporting one function and importing another one. The frontend
>> would use the exported function from the backend to send it commands.
>> The backend would do the same thing with the exported function from
>> the frontend:
>>
>> Visually, this is as follows:
>>
>> Frontend -->> Backend
>> Frontend <<-- Backend
>>
>> In my humble opinion, this may help getting rid of having to use
>> multithreading to avoid temporary frontend deadlocks. It also solves
>> the issue with zombies being created, and would permit me create a
>> responsive application but using the KISS principle.
>>
>>
>> Edward
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
> What about using unix domain sockets and a cleartext protocol?
>
> Nik
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Doing away with multi-threading in my project (netman)

[dr . klepp]

Am Mittwoch, 2. September 2015 schrieb Edward Bartolo:
> Hi all,
> 
> I think, I found an alternative to multithreading in netman. This is
> using interprocess communication, although what I have in mind may not
> be proper interprocess communication.
> 
> The idea is this: the backend would be converted into some sort of a
> daemon exporting one function and importing another one. The frontend
> would use the exported function from the backend to send it commands.
> The backend would do the same thing with the exported function from
> the frontend:
> 
> Visually, this is as follows:
> 
> Frontend -->> Backend
> Frontend <<-- Backend
> 
> In my humble opinion, this may help getting rid of having to use
> multithreading to avoid temporary frontend deadlocks. It also solves
> the issue with zombies being created, and would permit me create a
> responsive application but using the KISS principle.
> 
> 
> Edward
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

What about using unix domain sockets and a cleartext protocol?

Nik

-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Doing away with multi-threading in my project (netman)

[Edward Bartolo]

Hi all,

I think, I found an alternative to multithreading in netman. This is
using interprocess communication, although what I have in mind may not
be proper interprocess communication.

The idea is this: the backend would be converted into some sort of a
daemon exporting one function and importing another one. The frontend
would use the exported function from the backend to send it commands.
The backend would do the same thing with the exported function from
the frontend:

Visually, this is as follows:

Frontend -->> Backend
Frontend <<-- Backend

In my humble opinion, this may help getting rid of having to use
multithreading to avoid temporary frontend deadlocks. It also solves
the issue with zombies being created, and would permit me create a
responsive application but using the KISS principle.


Edward
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng