Re: Popen and EVFILT_WRITE question
- From: Mel <fbsd.hackers@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 1 Apr 2008 23:00:10 +0200
On Tuesday 01 April 2008 12:14:08 Dag-Erling Smørgrav wrote:
Mel <fbsd.hackers@xxxxxxxxxxxxxxxxxxxx> writes:
Dag-Erling Smørgrav <des@xxxxxx> writes:
it will either read input or it won't, and what happens when it
reads depends entirely on what the fd it reads from is connected to,
whether it's a slow or fast device, blocking or non-blocking, etc.
The kernel knows that the fd at the end of the pipe is blocked for
reading.
I'm not sure what you mean by that; do you mean that it's sleeping in
read() or similar? What if it uses select(), poll() or kqueue()
instead?
I was hoping the fd had some property "I'm blocked for reading".
Does it also know it's the end of a pipe and what's on the other end?
Cause it would be a cool filter to have, if you could detect a blocked
child as a parent. It sure is better then arbitrary timeouts (this code
will run 'make install' as a daemon(3) and write 'yes' on those nasty
post-install questions in ports).
Many ports will simply use the default configuration instead of asking
if you build them with -DBATCH.
Yeah, but that part is in the foreground, cause I don't want default values, I
want to be able to configure the ports and it's dependencies and then build
everything in the background (make config-recursive is flawed by design,
that's why I started building this).
Looks like BATCH is a good idea though. Thanks for making me look at that
again!
--
Mel
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- References:
- Re: Popen and EVFILT_WRITE question
- From: Dag-Erling Smørgrav
- Re: Popen and EVFILT_WRITE question
- Prev by Date: Re: Feature request
- Next by Date: seemingly good gdbinit for freebsd kernel errors out
- Previous by thread: Re: Popen and EVFILT_WRITE question
- Next by thread: Re: Feature request
- Index(es):
Relevant Pages
|