Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2006-06

Possible bug in thread manager

2 messages · 1 person ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Alexander Todorov

Hello,
I am sending you a sample which is not working as expected. The sample contains 2 FPC projects compiled with Lazarus. They are demonstrating a program that starts, goes in daemon mode, and creates two threads that will do their job, as well as the demonized program will do some job as well. This is shown with writelns. classthreads.lpr - threads implementation using TThread descendants systhreads.lpr - threads implementation using BeginThread functions To run as daemon pass some parameter on command line.

The two FPC implementations are pretty much the same. fork.c - a pthreads implementation in C. this is for reference only.

issue 1:
When demonising with LibC.Daemon(0, 0) the file handles to the standard Input, Output and Error are closed properly and they are not accessible to the created threads.
When the program is demonised using FpFork and closing the file hadles with Close() this is not working as expected. Thread1/Thread2 CAN write to the standard output and results get written in the console. When forking file handles are copied to the child process and changes are not visible to the parent or to the child. When creating threads the changes should be visible to the new threads since they are in the space of the process creating them. Am I right or not?

Issue 2:
When the program is compiled without {$DEFINE USE_DAEMON} it is being forked. In this case the second thread is not created (IMO), the masted program does not continue execution and all hangs up in the while loop for thread 1.
If it is started with without any parameters, it is running in non-daemon mode and the two threads are working fine. If started with & in the end two threads are working fine again.

The C reference uses fork() to become a daemon.
When the file handles for stdin, stdout, stderr are closed the threads don't print on the console.
If they are not closed the printed results are visible in console. In both cases the two threads and the master process are running.

For more info please see the provided source code and the provided listing of ps.
I am using FPC 2.0.2 on Linux.

Are these issues bugs in the thread manager?????
The projects are Linux (Unix) speciffic, can someone verify on Windows? Can someone test this with newer FPC?
A long time ago I saw an e-mail that anouced another ThreadManager implementation for FPC /something for real time threads IIRC/. Can someone test with different thread manager?

If these are bugs, 2 as I see it, should I report them in mantis?

Thanks to all.

Reply by email

Alexander Todorov
to Alexander Todorov
Alexander Todorov wrote 57 lines
Hello, I am sending you a sample which is not working as expected. The sample contains 2 FPC projects compiled with Lazarus. They are demonstrating a program that starts, goes in daemon mode, and creates two threads that will do their job, as well as the demonized program will do some job as well. This is shown with writelns. classthreads.lpr - threads implementation using TThread descendants systhreads.lpr - threads implementation using BeginThread functions To run as daemon pass some parameter on command line. The two FPC implementations are pretty much the same. fork.c - a pthreads implementation in C. this is for reference only. issue 1: When demonising with LibC.Daemon(0, 0) the file handles to the standard Input, Output and Error are closed properly and they are not accessible to the created threads. When the program is demonised using FpFork and closing the file hadles with Close() this is not working as expected. Thread1/Thread2 CAN write to the standard output and results get written in the console. When forking file handles are copied to the child process and changes are not visible to the parent or to the child. When creating threads the changes should be visible to the new threads since they are in the space of the process creating them. Am I right or not? Issue 2: When the program is compiled without {$DEFINE USE_DAEMON} it is being forked. In this case the second thread is not created (IMO), the masted program does not continue execution and all hangs up in the while loop for thread 1. If it is started with without any parameters, it is running in non-daemon mode and the two threads are working fine. If started with & in the end two threads are working fine again. The C reference uses fork() to become a daemon. When the file handles for stdin, stdout, stderr are closed the threads don't print on the console. If they are not closed the printed results are visible in console. In both cases the two threads and the master process are running. For more info please see the provided source code and the provided listing of ps. I am using FPC 2.0.2 on Linux. Are these issues bugs in the thread manager????? The projects are Linux (Unix) speciffic, can someone verify on Windows? Can someone test this with newer FPC? A long time ago I saw an e-mail that anouced another ThreadManager implementation for FPC /something for real time threads IIRC/. Can someone test with different thread manager? If these are bugs, 2 as I see it, should I report them in mantis? Thanks to all.

I forgot to add some details.
uname -a
Linux optical 2.4.27-1-386 #1 Fri Sep 3 06:24:46 UTC 2004 i686 GNU/Linux This is my developer machine.

I have a production machine that runs with a modified 2.6 kernel and the projects in question work on it.
I will give more details if needed.

Reply by email