«

Here's what I want do:

Have a main daemon which starts up several threads in a Boss-Queue structure.

From those threads, I want them all to sit and watch a queue. Once an entry
goes into the queue, grab it and run a system command.

Now I want to make sure that system command doesn't hang forever, so I need some
way to kill the command and have the worker thread go back to work waiting for
another queue entry.

Now the reason for the crossposting is because it could be done without threads.
I'm trying to figure out how to go about it, a non-blocking open() somehow? I
just now thought of popen(), but how to do so in a non-blocking way?

Any thoughts?

Jeff

On Thu, 04 Dec 2003 23:32:41 -0700, Jeff Rodriguez
<> wrote in comp.lang.c:

In the future please leave comp.lang.c out of your cross-post list
when asking platform specific questions, they are off-topic h ere.

> Here's what I want do:
>
> Have a main daemon which starts up several threads in a Boss-Queue structure.

There are no daemons or threads in the C language.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

Here is a real rough example on how to use popen(). I use this
technique quite often.

{
FILE *running;

running = popen("ls -l","r");

if (running)
{
fd_set rFds = {0};
int nFds = -1;

FD_SET(fileno(running),&rFds);
nFds = select(1+fileno(running),&rFds,0,0,0);
switch(nFds)
{
/* decode what happended here */
}
}
}

I'd recommend you use poll() for waiting (select() is easier for the
example). Then you can wait as long as you wish, and closing running
should signal a broken pipe to the process, thus terminating it.

I don't know if you need bi directional interaction with the other
process, but the theory will still be the same, you just need to handle
the "other" handle before the popen() call

Jeff Rodriguez wrote:
> Here's what I want do:
>
> Have a main daemon which starts up several threads in a Boss-Queue
> structure.
>
> From those threads, I want them all to sit and watch a queue. Once an
> entry goes into the queue, grab it and run a system command.
>
> Now I want to make sure that system command doesn't hang forever, so I
> need some way to kill the command and have the worker thread go back to
> work waiting for another queue entry.
>
> Now the reason for the crossposting is because it could be done without
> threads. I'm trying to figure out how to go about it, a non-blocking
> open() somehow? I just now thought of popen(), but how to do so in a
> non-blocking way?
>
> Any thoughts?
>
> Jeff
>

*** Rude top-posting fixed. Follow-ups set. ***

Joseph Dionne wrote:
> Jeff Rodriguez wrote:
> >
> > Have a main daemon which starts up several threads in a Boss-Queue
> > structure.
> >
> > From those threads, I want them all to sit and watch a queue. Once
> > an entry goes into the queue, grab it and run a system command.
> >
> > Now I want to make sure that system command doesn't hang forever,
> > so I need some way to kill the command and have the worker thread
> > go back to work waiting for another queue entry.
> >
> > Now the reason for the crossposting is because it could be done
> > without threads. I'm trying to figure out how to go about it, a
> > non-blocking open() somehow? I just now thought of popen(), but
> > how to do so in a non-blocking way?
>
> Here is a real rough example on how to use popen(). I use this
> technique quite often.
>
> {
> FILE *running;
>
> running = popen("ls -l","r");
>
> if (running)
> {
> fd_set rFds = {0};
> int nFds = -1;
>
> FD_SET(fileno(running),&rFds);
> nFds = select(1+fileno(running),&rFds,0,0,0);
> switch(nFds)
> {
> /* decode what happended here */
> }
> }
> }
>
> I'd recommend you use poll() for waiting (select() is easier for
> the example). Then you can wait as long as you wish, and closing
> running should signal a broken pipe to the process, thus
> terminating it.
>
> I don't know if you need bi directional interaction with the other
> process, but the theory will still be the same, you just need to
> handle the "other" handle before the popen() call

This thread is entirely off topic for c.l.c, inasmuch as the C
language knows zip about threads. C.l.c. also does not condone
top-posting.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[ comp.lang.c added back in ]

On Fri, 05 Dec 2003 17:43:53 +0000, CBFalconer wrote:

> This thread is entirely off topic for c.l.c, inasmuch as the C
> language knows zip about threads. C.l.c. also does not condone
> top-posting.

As a reader of comp.unix.programmer, where the thread is
relevant, may I humbly ask you lot on comp.lang.c to practice
what you preach by not cross-posting your replies about the
charter of comp.lang.c, which is off-topic on the other groups?

Thank you.

--
mail1dotstofanetdotdk

Bjorn Reese wrote:
> [ comp.lang.c added back in ]
>
> On Fri, 05 Dec 2003 17:43:53 +0000, CBFalconer wrote:
>
>
>>This thread is entirely off topic for c.l.c, inasmuch as the C
>>language knows zip about threads. C.l.c. also does not condone
>>top-posting.
>
>
> As a reader of comp.unix.programmer, where the thread is
> relevant, may I humbly ask you lot on comp.lang.c to practice
> what you preach by not cross-posting your replies about the
> charter of comp.lang.c, which is off-topic on the other groups?
>

Sorry, no. That's not a reasonable request. It does no good for us to
tell others in comp.lang.c that a message is off-topic here while people
in other groups merrily cross post more and more off-topic replies to
our group. When somebody cross-posts an off-topic message, we have to
ask the other groups to remove us from the cross-post list when
replying. I expect people in any other group to do the same, and
certainly wouldn't complain if a member of some other group replied to a
cross post in c.l.c to tell us that the thread is not topical in their
group. In fact, it's nice to know, since it removes all doubt about
whether a reply should be cross-posted back to that group or not.

We in comp.lang.c do our best to be good neighbors. We're sorry for the
noise, but blame the original cross-poster, not us.

Disclaimer: I don't speak for the whole group. Any or all of the other
members of c.l.c may disagree with me.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

In article <4b5Ab.352$_ >,
Kevin Goodsell <> wrote:

> We in comp.lang.c do our best to be good neighbors. We're sorry for the
> noise, but blame the original cross-poster, not us.

No you don't, and I don't think you're sorry. I've never seen any other
group be so routinely hostile to innocent newbies who don't know any
better. Their thinking was probably something like "I'm programming on
Unix in C, so I'll ask in the Unix and C groups." Is that *so*
unreasonable that they need to be made to feel like idiots?

You can clearly see that the message is cross-posted to a Unix group.
Then when it makes mention of a Unix function (which you probably knew
was going to happen) you typically give some kind of sarcastic response,
embarassing them as if they're the first one to ever have made this
mistake.

We occasionally get questions in comp.unix.programmer that are about
straight C, with nothing Unix-specific. I've rarely seen anyone here
respond "Sorry, that's not a Unix question, go ask in comp.lang.c." We
answer them, and then perhaps mention your fine newsgroup (as well as
some related alt.learn groups, if it seems appropriate) for future
questions of the same type.

You guys are like a grumpy neighbor. Kids don't want their ball to get
thrown into his yard by accident, because he won't give it back without
a fight.

--
Barry Margolin,
Woburn, MA

On Sat, 06 Dec 2003 10:05:08 GMT, in comp.lang.c , Barry Margolin
<> wrote:

>In article <4b5Ab.352$_ >,
> Kevin Goodsell <> wrote:
>
>> We in comp.lang.c do our best to be good neighbors. We're sorry for the
>> noise, but blame the original cross-poster, not us.
>
>No you don't, and I don't think you're sorry.

You misjudge Kevin in specific, and CLC in general.

>I've never seen any other
>group be so routinely hostile to innocent newbies who don't know any
>better.

There are for sure some people here who're overagressive. Its
certainly far from the most hostile group tho.

>Their thinking was probably something like "I'm programming on
>Unix in C, so I'll ask in the Unix and C groups." Is that *so*
>unreasonable that they need to be made to feel like idiots?

Go not to the elves for counsel, for they shall say "newbies ought to
follow nettiquette and lurk before posting, and yet by definition
newbies may not know that"

>We occasionally get questions in comp.unix.programmer that are about
>straight C, with nothing Unix-specific. I've rarely seen anyone here
>respond "Sorry, that's not a Unix question, go ask in comp.lang.c." We
>answer them,

Probably because any straight C question is by definition entirely
within the scope of unix programming?


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Fri, 05 Dec 2003 19:40:48 +0000, Kevin Goodsell wrote:

> our group. When somebody cross-posts an off-topic message, we have to
> ask the other groups to remove us from the cross-post list when
> replying. I expect people in any other group to do the same, and
> certainly wouldn't complain if a member of some other group replied to a
> cross post in c.l.c to tell us that the thread is not topical in their

All other groups that I am subscribed to uses a different tactic
to handle off-topic postings; they ignore them. Only comp.lang.c
feels compelled to teach everybody about their charter.

As long as comp.lang.c uses their tactic within their own group
I am not going to object, but I have a problem when they
cross-post to other groups, and set the follow-up to all groups
except their own group. Discussions about the charter of
comp.lang.c are topical on comp.lang.c and only there, so the
follow-up should be set to comp.lang.c and not any other group.

> We in comp.lang.c do our best to be good neighbors. We're sorry for the
> noise, but blame the original cross-poster, not us.

The original poster will be educated about the comp.lang.c charter
by the replies that are sent exclusively to comp.lang.c.

Should any replies omit to remove comp.lang.c from the cross-
posting then I am sorry about the noise, but at least you have
the posibility to killfile the thread -- we don't because the
thread, apart from the postings about what is topical on
comp.lang.c, is topical on our groups.

I do not perceive the comp.lang.c charter cross-posting, nor your
refusal to respect the charters of other groups, as good
neighborship.

Please respect the fact that discussions about what is and is not
topical on comp.lang.c are not topical on other groups.

Thank you.

--
mail1dotstofanetdotdk

On Sat, 06 Dec 2003 17:02:08 +0100, in comp.lang.c , "Bjorn Reese"
<> wrote:

>All other groups that I am subscribed to uses a different tactic
>to handle off-topic postings; they ignore them. Only comp.lang.c
>feels compelled to teach everybody about their charter.

actually, we don't have one - the group predates the charter system.

>As long as comp.lang.c uses their tactic within their own group
>I am not going to object, but I have a problem when they
>cross-post to other groups, and set the follow-up to all groups
>except their own group. Discussions about the charter of
>comp.lang.c are topical on comp.lang.c and only there, so the
>follow-up should be set to comp.lang.c and not any other group.

agreed.

>> We in comp.lang.c do our best to be good neighbors. We're sorry for the
>> noise, but blame the original cross-poster, not us.
>
>The original poster will be educated about the comp.lang.c charter
>by the replies that are sent exclusively to comp.lang.c.

only if he reads it.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---