[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
error_t
pipe_pair_select (struct pipe *rpipe, struct pipe *wpipe,
int *select_type, int data_only)
{
....
condition_implies (&rpipe->pending_read_selects,
&pending_read_write_select);
condition_implies (&wpipe->pending_write_selects,
&pending_read_write_select);
....
if (hurd_condition_wait (&pending_read_write_select, lock))
err = EINTR;
....
condition_unimplies (&rpipe->pending_read_selects,
&pending_read_write_select);
condition_unimplies (&wpipe->pending_write_selects,
&pending_read_write_select);
}
pending_read_write_select are broadcasted in some functions along pipe.c
code.
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?
Thanks,
Vicente.