[fpc-devel] Possible bug in thread manager

[Alexander Todorov]

On 6/1/06, Alexander Todorov <alexx.todorov at gmail.com> wrote:
> 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.
alex at optical:~$ 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.