[Sbcl-help] sb-posix:fork during *init-hooks*

[Siebe]

Hi,

We call sb-daemon:daemonize in a hook on *init-hooks*, which calls
sb-posix:fork.

Since sbcl-2.1.8 there is (in NEWS) "minor incompatible change: the hooks
in *INIT-HOOKS* are called before starting the finalizer or other non-user
threads.  (thanks to Sean Whitton)".

That change is indeed incompatible, because sb-posix:fork insists on
stopping the finalizer and an aver is raised when no such thread is running.

Are we using a wrong scenario to daemonize?

Otherwise, the attached patch checks if there is a finalizer thread in
sb-posix:fork. Alternatively, the same check might also be built into
finalizer-thread-stop itself to prevent the same issue in any code that is
called from *init-hooks*.

Thanks,

Siebe

[Douglas Katzman via Sbcl-help]

I'd really prefer not to complicate any logic around whether a finalizer thread exists. 

Is there a reason for not putting fork into whatever would otherwise be the top-level of your application?

To me, init-hooks have the wrong feel about them for doing application logic such as that, especially being that fork is a fairly heavyweight concept.

(In retrospect, I don't necessarily like Sean Whitton's patch either - why are anybody's init-hooks sensitive to the fact that a thread doesn't exist?)

_______________________________________________
Sbcl-help mailing list
Sbcl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Siebe]

Our application runs only as a daemon, so we take care of that at the first
opportunity. It also prevents processing of --eval, --load, or init files
before we have checked some things. Anyway, I think we can get what we want
when we move this stuff to a toplevel function.

The original patch was indeed rather for a niche case and also against
expectations of SBCL developers: sb-vm::!setup-cpu-specific-routines got
added later and is now also not available during *init-hooks*.

Thanks,
S.

On 17/08/2023 18.24, Douglas Katzman wrote:
> I'd really prefer not to complicate any logic around whether a finalizer
> thread exists.
> Is there a reason for not putting fork into whatever would otherwise be the
> top-level of your application?
> To me, init-hooks have the wrong feel about them for doing application
> logic such as that, especially being that fork is a fairly heavyweight concept.
> (In retrospect, I don't necessarily like Sean Whitton's patch either - why

> are anybody's init-hooks sensitive to the fact that a thread /doesn't/ exist?)

>
>
> On Thu, Aug 17, 2023 at 11:54 AM Siebe <si...@de-vos.de
> <mailto:si...@de-vos.de>> wrote:
>
> Hi,
>
> We call sb-daemon:daemonize in a hook on *init-hooks*, which calls
> sb-posix:fork.
>
> Since sbcl-2.1.8 there is (in NEWS) "minor incompatible change: the hooks
> in *INIT-HOOKS* are called before starting the finalizer or other non-user
> threads.  (thanks to Sean Whitton)".
>
> That change is indeed incompatible, because sb-posix:fork insists on
> stopping the finalizer and an aver is raised when no such thread is
> running.
>
> Are we using a wrong scenario to daemonize?
>
> Otherwise, the attached patch checks if there is a finalizer thread in
> sb-posix:fork. Alternatively, the same check might also be built into
> finalizer-thread-stop itself to prevent the same issue in any code that is
> called from *init-hooks*.
>
> Thanks,
>
> Siebe
>
> _______________________________________________
> Sbcl-help mailing list

> Sbcl...@lists.sourceforge.net <mailto:Sbcl...@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
> <https://lists.sourceforge.net/lists/listinfo/sbcl-help>