Professional Web Applications Themes

How do I: Main thread spawn child threads, which child processes...control those child processes? - UNIX Programming

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 ...

  1. #1

    Default How do I: Main thread spawn child threads, which child processes...control those child processes?

    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

    Jeff Guest

  2. #2

    Default Re: How do I: Main thread spawn child threads, which child processes... control those child processes?

    On Thu, 04 Dec 2003 23:32:41 -0700, Jeff Rodriguez
    <EXAMPLENOSPAM.com> 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.
     

    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
    Jack Guest

  3. #3

    Default Re: How do I: Main thread spawn child threads, which child processes...control those child processes?

    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: 

    Joseph Guest

  4. #4

    Default Re: How do I: Main thread spawn child threads, which childprocesses...control those child processes?

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

    Joseph Dionne wrote: 
    >
    > 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[/ref]

    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 (com) (att.net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!


    CBFalconer Guest

  5. #5

    Default Re: How do I: Main thread spawn child threads, which child processes...control those child processes?

    [ comp.lang.c added back in ]

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

    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 Guest

  6. #6

    Default Re: How do I: Main thread spawn child threads, which child processes...controlthose child processes?

    Well, technically, the 'c' language knows zip about sockets, however we
    discuss sockets here.

    CBFalconer wrote: 
    >>
    >>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[/ref]
    >
    >
    > 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.
    >[/ref]

    Joseph Guest

  7. #7

    Default [OT] Polite cross-posting (was: How do I: Main thread spawn childthreads..._

    Bjorn Reese wrote: 
    >
    >
    > 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?
    >[/ref]

    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.

    Kevin Guest

  8. #8

    Default Re: How do I: Main thread spawn child threads, which child processes...controlthose child processes?

    Joseph Dionne 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.
    >>[/ref]
    >[/ref]
    Ok, say I do use popen. How do I get the PID of my child process?

    I'm sure I can figure out how to kill it if it becomes unruly, but first I need
    it's PID. That seems to be the way to go I think, unless anyone else has any
    other ideas?


    Jeff

    Jeff Guest

  9. #9

    Default Re: How do I: Main thread spawn child threads, which child processes...controlthose child processes?

    Jeff Rodriguez wrote:
     
    >>[/ref]
    > Ok, say I do use popen. How do I get the PID of my child process?
    >
    > I'm sure I can figure out how to kill it if it becomes unruly, but first
    > I need it's PID. That seems to be the way to go I think, unless anyone
    > else has any other ideas?
    >
    >
    > Jeff
    >[/ref]
    Actually, I just found this little tidbit:
     

    Does anyone have objections to using that method for any reason? I would think
    this cause duplicates of much of the memory already in use by the parent
    process, is that memory free()'d when I use one of the exec*() functions?

    Now what if I wanted to do bi-directional communication with that process... do
    the exec*() functions destory all variables (pertains to previous paragraph). If
    I didn't want to use a file in the operating system, how would I communicate
    between the two?

    Jeff

    Jeff Guest

  10. #10

    Default [OT now] Re: How do I: Main thread spawn child threads, which childprocesses...control those child processes?

    Jeff Rodriguez wrote:
     
    >> Ok, say I do use popen. How do I get the PID of my child process?
    >>
    >> I'm sure I can figure out how to kill it if it becomes unruly, but
    >> first I need it's PID. That seems to be the way to go I think, unless
    >> anyone else has any other ideas?
    >>
    >>
    >> Jeff
    >>[/ref]
    > Actually, I just found this little tidbit:

    > value), 
    > spawn a 
    >
    > Does anyone have objections to using that method for any reason? I would
    > think this cause duplicates of much of the memory already in use by the
    > parent process, is that memory free()'d when I use one of the exec*()
    > functions?
    >
    > Now what if I wanted to do bi-directional communication with that
    > process... do the exec*() functions destory all variables (pertains to
    > previous paragraph). If I didn't want to use a file in the operating
    > system, how would I communicate between the two?
    >
    > Jeff
    >[/ref]
    Apologies, this just became off-topic for c.p.t

    Thank you for your help.

    Jeff

    Jeff Guest

  11. #11

    Default Re: How do I: Main thread spawn child threads, which child processes...control those child processes?


    "Jeff Rodriguez" <EXAMPLENOSPAM.com> wrote in message
    news:EXAMPLENOSPAM.com...
     [/ref]
    value), [/ref]
    a [/ref]
     
    think 

    Fortunately, duplication is nearly free on every modern UNIX. The memory
    is not freed because it's still in use by the other copy, its reference
    count is reduced though.
     
    process... do 
    paragraph). If 
    communicate 

    You would open a pipe before calling 'fork'. After 'fork', the parent
    would close one end of the pipe and the child would close the other.
    Commonly, the child's pipe end is then 'dup2'd onto stdin, stdout, or
    stderr. Then you call 'exec'.

    DS


    David Guest

  12. #12

    Default Re: How do I: Main thread spawn child threads, which child processes...control those child processes?


    Jeff Rodriguez <EXAMPLENOSPAM.com> writes:
     
    > > Ok, say I do use popen. How do I get the PID of my child process?
    > >
    > > I'm sure I can figure out how to kill it if it becomes unruly, but first
    > > I need it's PID. That seems to be the way to go I think, unless anyone
    > > else has any other ideas?
    > >
    > >
    > > Jeff
    > >[/ref]
    > Actually, I just found this little tidbit:
    > [/ref]

    Well, popen() uses fork and exec too. I would put it a different way,
    and say that if the standard popen() doesn't meet your needs, you may
    need to code a custom version that does what you want.
     

    Why are you worrying about this? The only process on a Unix system
    that isn't created by a fork/exec, is init. popen() uses fork/exec,
    and so does system().
     

    You need to decide whether bi-directional communication is a requirement.
    If it is, then you should first determine whether the standard popen()
    will support that. Some OS's (e.g. Solaris, FreeBSD) have pipes that allow
    bi-directional communication, and others (e.g. Linux) don't.

    If you need bi-directional communication, then you will definitely need to
    do a custom popen(), since you will need separate pipes for the child process's
    stdin and stdout.

    If you wish to avoid threads and instead monitor multiple child processes
    using select(), then there is another issue, which is that popen() provides
    a buffered IO stream (FILE *) rather than a file descriptor. You will need
    the file descriptor for select(). You can get the underlying file descriptor
    using fileno(), and you can make it non-blocking for use with select() via
    fcntl(). But you need to be very careful if you are mixing buffered IO
    (fread, fscanf, etc. ) with select(), since select doesn't know whether
    there is data in the buffer.

    I would start with standard popen(), and see how far I got with that.
    You may find that popen() doesn't provide any advantages compared to
    system(), or you may find that you need to customize popen() for your
    needs.

    -SEan








    Sean Guest

  13. #13

    Default Re: [OT] Polite cross-posting (was: How do I: Main thread spawn child threads..._

    In article <4b5Ab.352$news.pas.earthlink.net>,
    Kevin Goodsell <com> wrote:
     

    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, mit.edu
    Woburn, MA
    Barry Guest

  14. #14

    Default Re: How do I: Main thread spawn child threads, which child processes...control those child processes?

    In article <EXAMPLENOSPAM.com>,
    Jeff Rodriguez <EXAMPLENOSPAM.com> wrote:
     
    >
    > Does anyone have objections to using that method for any reason? I would
    > think
    > this cause duplicates of much of the memory already in use by the parent
    > process, is that memory free()'d when I use one of the exec*() functions?[/ref]

    exec() completely replaces the process's memory with that of the new
    program. Think about it: except for the init process that's created at
    boot time, every process on Unix was created by forking and usually
    exec'ing something immediately thereafter. Every program run from the
    shell was fork/exec'ed by the shell. By the time you get to an
    application program, you're at least 4 levels deep in this, and it would
    make little sense if each one of them were layered on top of a copy of
    the parent rather than replacing it.
     

    Use a pair of pipes, one for parent->child and the other for
    child->parent. Some operating systems support bidirectional
    communications through a single pipe, but if portability is a concern
    you shouldn't depend on this.

    --
    Barry Margolin, mit.edu
    Woburn, MA
    Barry Guest

  15. #15

    Default Re: How do I: Main thread spawn child threads, which child processes...control those child processes?

    In article <xenadyne.com>,
    Sean Burke <org> wrote:
     

    Even though the underlying pipes may support bidrectional communication,
    popen() returns a stdio stream that's only open in one direction. I
    guess you could use fileno() to get the pipe descriptor and bypass
    stdio, but I'm not sure how well stdio will deal with it when you
    finally call fclose(). Mixing Unix I/O and stdio is not for beginners;
    if he can't program fork/exec himself, he's probably not ready to deal
    with that.

    --
    Barry Margolin, mit.edu
    Woburn, MA
    Barry Guest

  16. #16

    Default Re: [OT] Polite cross-posting (was: How do I: Main thread spawn child threads..._

    On Sat, 06 Dec 2003 10:05:08 GMT, in comp.lang.c , Barry Margolin
    <mit.edu> wrote:
     
    >
    >No you don't, and I don't think you're sorry.[/ref]

    You misjudge Kevin in specific, and CLC in general.
     

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

    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"
     

    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 =---
    Mark Guest

  17. #17

    Default Re: [OT] Polite cross-posting (was: How do I: Main thread spawn child threads..._

    On Fri, 05 Dec 2003 19:40:48 +0000, Kevin Goodsell 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.

    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.
     

    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

    Bjorn Guest

  18. #18

    Default Re: [OT] Polite cross-posting (was: How do I: Main thread spawn child threads..._

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

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

    agreed.
     
    >
    >The original poster will be educated about the comp.lang.c charter
    >by the replies that are sent exclusively to comp.lang.c.[/ref]

    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 =---
    Mark Guest

  19. #19

    Default Re: [OT] Polite cross-posting (was: How do I: Main thread spawn child threads..._


    On Sat, 6 Dec 2003, 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.[/ref]

    No charter for c.l.c -- it's been around longer than the charter
    system, apparently. We do have a FAQ or two, though.
     

    The rationale for that is: This is off-topic on c.l.c, but not
    c.u.p.
    Suppose I (in c.l.c) do nothing. Then c.l.c is flooded with
    off-topic posts cross-posted from c.u.p. That's bad.
    Suppose I (in c.l.c) post a message to c.l.c only, telling the
    OP it's off-topic. That might educate the OP, but probably not --
    he doesn't read c.l.c. (If he did, he wouldn't post OT questions
    here. QED.) And since nobody in c.u.p will see the message, it
    won't stop the flood of OT posts either.
    Suppose I (in c.l.c) post a message to c.u.p only, telling the
    OP it's off-topic. That has a higher chance of educating the OP,
    but it would be uncouth -- because without any post in c.l.c, the
    members won't see that the OP has been re-directed, and *c.u.p*
    will be flooded by c.l.c redirection messages!
    Suppose I (in c.l.c) post a message to c.u.p and c.l.c both,
    telling the OP it's off-topic. That will probably educate the
    OP (since he must be reading *some* group), and if all goes well
    it will be noticed by the folks in c.u.p too, and they will stop
    posting OT stuff to c.l.c.
    Setting the followups to exclude c.l.c keeps the OT (sub-)thread
    from reappearing in the newsgroup in which it is OT. Unfortunately,
    it *is* counter-productive, in that it tends to off people
    in other groups, who then flood c.l.c with threads like this
    one, complaining about how the followup list was pared.
     

    Reasonable. The central problem, the Catch-22, is that we
    can't get rid of an annoying thread without re-directing the poster,
    and we can't re-direct the poster without risking the start of
    another annoying sub-thread like this one.
    If only everyone would read the FAQs and some general guides
    to Usenet etiquette, we would hardly ever have this problem. I
    tend to agree with you -- c.l.c *is* a grumpy old man into whose
    yard it is unwise to hit baseballs. But it's only gotten that way
    because *every week* a new kid moves into the house next door and
    the *first* thing he does is hit a baseball through our window.
    *Every week.* It produces a bit of institutionalized grumpiness
    after a while.
    FWIW, many of the newbies who post *only* to c.l.c get redirected
    in a more friendly manner. That may be due partly to the fact that
    we know that after they get redirected, the thread will *die*, and
    not be kept alive by some idjits in a whole 'nother group who have
    never been told to snip c.l.c from followups. <half-smiley>

     

    No, he obviously *won't*. He doesn't *read* c.l.c -- if he ever
    had, he'd have seen the kinds of questions that are topical here.
    And if he ever *planned* to read c.l.c, he'd have Googled the FAQ
    himself. Thus we can only conclude that he must be reading from
    your side of the fence. Sorry.
     

    Yes, I'm sorry about that too. Catch-23: If we added a
    [TOPICALITY] tag to the thread, then c.u.p could killfile it.
    But if we change the subject line, then Google Groups will
    spawn a new thread and the OP might not see the sub-thread at
    all -- and thus he'd keep doing it. :-(
     

    I highly doubt that the original topicality-policeman *intended*
    to start a "discussion." We just want the things that are off-topic
    on *our* group to stay *out*. Discussion is not necessary. (Catch-
    24: I can't impart my information to you unless I join the
    discussion. And the information I want to impart is that discussion
    is counter-productive.)

    Now please everyone let this thread die. And next time you see
    an off-topic thread in c.u.p (or anywhere), just re-direct the OP
    and then shut up. And remember, in your redirection, to tell the
    OP to shut up too, lest we start another of *these*. :-)

    -Arthur
    Arthur Guest

  20. #20

    Default Re: [OT] Polite cross-posting

    Barry Margolin wrote:
     
    >
    >
    > 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?[/ref]

    First, groups aren't hostile. (Some) people are.

    Second, if the "newbies" observed some basic netiquette rules then there
    wouldn't be a problem. c.l.c provides countless man-hours of free
    support, and asks nothing in return. All that we ask is that people
    follow the basic rules of Usenet. When they don't, some people become
    hostile.
     

    Yes, I can clearly see the cross-post list. But it's also easy to miss.
    I assume that most of the time when a response like that is
    cross-posted, it's because the person didn't realize that the original
    message (or their reply) was being cross-posted. Personally, I usually
    post a polite reply addressing the other groups and asking them to
    remove comp.lang.c from the cross-post list when replying.
     

    That sounds quite appropriate. Straight C questions can usually be
    addressed better in comp.lang.c, so a redirection is good for everyone.
    But you should realize that it's not quite the same thing as a Unix
    question in comp.lang.c. Many people here don't program for Unix at all,
    and we are generally not well-equipped to answer those questions. This
    is, of course, the reason we have different groups with different topics
    - so that a question can reach those who can best answer it, while not
    wasting the time of those who not only cannot answer it, but have no
    interest in it.
     

    This depends very much on the kid. We don't like rude children (who
    does?), but we're quite fond of the ones that are respectful and
    interested in learning from us.

    I actually really like that ogy. It seems very appropriate. That is,
    if you consider that the neighbor is grumpy because he's had to deal
    with so many rude kids, but he can be quite pleasant as long as you
    don't get on his bad side.

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

    Kevin Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Parent/Child relations - Trying to access child control for save
    By tnt_lu@hotmail.com in forum ASP.NET Data Grid Control
    Replies: 0
    Last Post: April 15th, 12:50 PM
  2. Placeholder child of child control event problem.
    By caldera in forum ASP.NET Building Controls
    Replies: 1
    Last Post: May 28th, 07:56 AM
  3. child processes
    By Vikas Vijay in forum UNIX Programming
    Replies: 2
    Last Post: July 24th, 09:22 AM
  4. Limiting child processes in a sub-shell
    By Peter in forum Sun Solaris
    Replies: 0
    Last Post: July 3rd, 02:22 AM
  5. Managing linked list through child processes
    By Barry Margolin in forum UNIX Programming
    Replies: 0
    Last Post: June 30th, 05:57 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139