On Sun, Nov 17, 2002 at 09:30:55PM -0500, Richard Kreuter wrote:
> The following trivial patch adds support for partitions of type f to
> the OSKit, and so to oskit-mach.
Hi,
thanks a lot. Can you submit this to the Debian BTS for the oskit package
(simply add a pseudo header:
Package: oskit
i
Richard Kreuter <[EMAIL PROTECTED]> writes:
> On Thu, Nov 14, 2002 at 12:08:21AM +0800, Bin Ren wrote:
> > Richard Kreuter wrote:
> > >On Wed, Nov 13, 2002 at 08:20:04PM +0800, Bin Ren wrote:
> > >
> > > >I've successfully compiled and installed OSKit Mach and added
> > > >proper line to grub.conf
> > What about non-Mach backends? I would feel better about an
> > internal-interface-guarantee argument rather than an implementation
> > argument.
>
> This requirement is part of the interface; I was using Mach for
> illustration purposes because I assume that Vincente is familiar with
> Mach c
> Linux futexes have the exact same problem and they solve it similarly:
I should add that I have not looked at the latest implementation of
futexes. The description is based on my reading of Hubertus Franke,
Rusty Russell and Matthew Kirkwood's paper "Fuss, Futexes and
Furwocks: Fast Userlevel L
> What about non-Mach backends? I would feel better about an
> internal-interface-guarantee argument rather than an implementation
> argument.
This requirement is part of the interface; I was using Mach for
illustration purposes because I assume that Vincente is familiar with
Mach concepts. On,
On Sun, Nov 17, 2002 at 12:24:03PM -0500, Neal H. Walfield wrote:
> > Is there a race condition before __pthread_block? We can receive
> > pthread_broadcast before we have blocked.
> > If so, how do we solve that?
>
> As I said in a previous email, a __pthread_wakeup queues a message on
> the wai
On Sat, Nov 16, 2002 at 11:45:18AM +0100, Robert Millan wrote:
> > But the bits about OCRNL, TABDLY and TAB3 seems to be wrong. They're
> > all required by POSIX.
>
> I didn't know that. Well, in any case they're features we don't have
> yet. When they are implemented the code will recompile with
> Is there a race condition before __pthread_block? We can receive
> pthread_broadcast before we have blocked.
> If so, how do we solve that?
As I said in a previous email, a __pthread_wakeup queues a message on
the waiter's port (using mach_msg). If this happens before the waiter
calls does a r
El dom, 17-11-2002 a las 16:30, Neal H. Walfield escribió:
> > Is there a replacement for CPROC_SWITCHING and CPROC_RUNNING in
> > cproc_t->state, to know if a thread has been waken up?
>
> No. We do not need it.
>
I should have sent more info last message.
> > Can a thread be waken up if it ha
> Is there a replacement for CPROC_SWITCHING and CPROC_RUNNING in
> cproc_t->state, to know if a thread has been waken up?
No. We do not need it.
> __pthread.state has the following states...
>
> /* Thread state. */
> enum pthread_state
> {
> PTHREAD_JOINABLE = 0,
> PTHREAD_DETACHED,
>
El sáb, 16-11-2002 a las 22:01, Neal H. Walfield escribió:
> > /* Just like pthread_condition_wait, but cancellable. Returns true if
> > cancelled. */
> > int
> > hurd_pthread_cond_wait (pthread_cond_t c, pthread_mutex_t m)
>
> I see no reason to rename this function.
As long as cthread and pth
11 matches
Mail list logo
