[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cthread2Pthread

From: Vicente Hernando Ara
Subject: Re: Cthread2Pthread
Date: 15 Dec 2002 04:19:07 +0100

Hi all!

Sorry for the delay on continuing this thread. ;) 

El lun, 02-12-2002 a las 19:25, Marcus Brinkmann escribió:
> On Mon, Dec 02, 2002 at 09:13:20AM -0800, Thomas Bushnell, BSG wrote:
> > Roland McGrath <roland@gnu.org> writes:
> > 
> > > > We still need a way to keep track of what they are, and the existing
> > > > mechanism is basically the only way.  We can either implement it with
> > > > a wrapper around pthread conditions, or exted pthread conditions.  The
> > > > latter seems better.
> > > 
> > > Or, as I suggested, all the users (all four of them) of this interface
> > > could just use the standard interface instead, i.e. signal several conds.
> > 
> > Right, and like I said, they need a way to keep track of which
> > conditions they need to signal.  They will probably hold them on a
> > linked list, and call one function that signals the lot.  Oh wait!
> > That's what we have now!
> > 
> > So the question is only whether this is to be layered on top of
> > pthreads, or an extension of pthreads.
> Roland was talking about hard coding the knowledge into the code.
> Ie, a very simple condition_signal (cond1); condition_signal (cond2);
> instead some foobar_signal(cond1) which somehow dynamically works out what
> conditions are implied by cond1.
> I like the nice modularity and runtime flexibility that implied conditions
> give you, but I see Roland's point: We don't really need it in our code.
> Thanks,
> Marcus
I actually agree more with Thomas, but I also think I dont understand
well the code. ;)

In example: At hurd/libpipe/pipe.c

pipe_pair_select (struct pipe *rpipe, struct pipe *wpipe,
                  int *select_type, int data_only)
    condition_implies (&rpipe->pending_read_selects,
    condition_implies (&wpipe->pending_write_selects,
    if (hurd_condition_wait (&pending_read_write_select, lock))
       err = EINTR;
    condition_unimplies (&rpipe->pending_read_selects,
    condition_unimplies (&wpipe->pending_write_selects,

pending_read_write_select are broadcasted in some functions along pipe.c

So, the question is:
Can the broadcast be as easy as 
at pipe_pair_select  function:
  /* When implicating conditions. */
  implication = &pending_read_write_select;
  /* When unimplicating conditions. */
  implication = NULL;

and when condition are broadcasted..

  if (implication != NULL)
    pthread_cond_broadcast (implication);

or instead we need a list of implicated conditions, which makes
condition_implies function more interesting?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]