does smbmount need to fork?

[David Wuertele]

I'm writing an smbmount replacement using libsmbclient.  It
automatically discovers, mounts, and unmounts SMB shares according to
some internal logic.  I've implemented my program by following the
same API that smbmount uses, and in fact I've implemented
functionality in the same executable that performs the equivalent of
what smbmnt does.  So far everything is working swell.

Unfortunately, there is a step where smbmount forks so that a daemon
may survive to handle SIGUSR1 --- and my replacement does the same
thing.  This is unfortunate, because every time my program forks, its
huge memory space is copied, and when I'm mounting a lot of shares
(sometimes over 30 at once), this takes a lot of memory.

I'd prefer to not have to fork at all.  I realize that the kernel
needs to send a SIGUSR1 to somebody to initiate a server-reconnect.
Is there a way to manage multiple mounts in a single process?  Can my
monolithic process's signal handler figure out from the SIGUSR1 signal
which mount point it is meant for?

I would rather not use threads, but if the signal handler can't
distinguish the mount point it may be the only way.  At least threads
would be better than forking from the resource perspective.  Can the
kernel distinguish between threads when it does 
kill_proc(pid, SIGUSR1, 1)?  Will the appropriate thread be the only
one to get the SIGUSR1?  Is this the best way to achieve what I want?

Thanks,
Dave

PS my program only has to work on Linux.