Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Dec 1998 21:39:16 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        info@highwind.com (HighWind Software Information)
Cc:        tlambert@primenet.com, current@FreeBSD.ORG
Subject:   Re: Thread fd locking and fork()
Message-ID:  <199812052139.OAA27659@usr05.primenet.com>
In-Reply-To: <199812042207.RAA12304@highwind.com> from "HighWind Software Information" at Dec 4, 98 05:07:58 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >   Then don't explicitly call close after the exec, since the fork()
> >   wrapper in libc_r will Do The Right Thing(tm).
> 
> What is the problem with calling close() after the exec()? That is a
> 100% valid thing to do.

Sure.

But calling close() after the fork() but before the exec() isn't.

This is because threads aren't expected to start processes.  If
threads are a good idea at all, then you'd be starting a thread;
if they aren't, well, then why are you running threads in the
first place?


> Saying, "do this instead" is nice, but doesn't address the bug in
> libc_r.
> 
> Also, if you call fcntl() after the fork(), you will hang. The only
> thing you can do is fcntl() all your descriptors before the fork().

Yep.  Better if you do this right after openiong them, in fact,
before giving the processor context away to another thread.


> That is a bit crazy because you have to juggle everytime you want to
> do a fork()/exec(). Calling fcntl() in the parent also introduces
> other race conditions as other parts of the system might be calling
> fork().
> 
> My patch seems to fix it.

Your patch is actually not the right thing to do; it leaves an
orphan reference around.

Also, consider that after a fork you have a copy of the process,
including the threads scheduler, etc..  It's quite possible that
your thread will be involunarily context switched by receipt of a
signal, and you will end up actually running two copies of the
thread code until you context switch into the thread that wanted
to exec.  This is bad.

Probably the correct thing to do is to use vfork(), so you don't
have to contend with other threads.

Unfortunately, some idiot broke vfork() (HINT: try to set up
vacation with a response message, and see if you get the message).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812052139.OAA27659>