> This is why I was insisting on passing *memory* through IPC.
It's not at all clear that makes any kind of sense, unless you mean
something I haven't imagined. Can you be specific about exactly what the
interface (say, a well-commented MiG .defs fragment) you have in mind would
look like?
If i
On Sat, Jan 18, 2014 at 02:06:05AM +0100, Samuel Thibault wrote:
> Diego Nieto Cid, le Fri 17 Jan 2014 22:49:25 -0200, a écrit :
> > El ene 17, 2014 11:36 a.m., "Marin Ramesa" escribió:
> > > +
> > > +kern_return_t
> > > +futex_wait(task_t task, vm_offset_t futex_address, int value,
> > > +
Diego Nieto Cid, le Fri 17 Jan 2014 22:49:25 -0200, a écrit :
> El ene 17, 2014 11:36 a.m., "Marin Ramesa" escribió:
> > +
> > +kern_return_t
> > +futex_wait(task_t task, vm_offset_t futex_address, int value,
> > + mach_msg_timeout_t msec, boolean_t private_futex)
> > +{
> > + if (p
El ene 17, 2014 11:36 a.m., "Marin Ramesa" escribió:
>
> +
> +kern_return_t
> +futex_wait(task_t task, vm_offset_t futex_address, int value,
> + mach_msg_timeout_t msec, boolean_t private_futex)
> +{
> + if (private_futex) {
> + struct private_futex *futex;
> +
> +
Please always keep the mailing list in Cc, so you optimize the chance of getting
a complete answer in a minimized time. Otherwise, you run the risk of either
get a terse answer, or have to wait (possibly long) that I have time to provide
a lengthier answer (or simply that I come back from vacation
So I was reading about system calls this week and I noticed that generally
we write wrappers which handle the syscalls from programs. So if a system
call is encountered, it calls this wrapper which then makes calls to the
kernel to perform the task.
So I presume that this wrapper is glibc in Hurd,
On 01/17/2014 03:56:39 PM, Justus Winter wrote:
Sounds promising, if they are in a shape to be presented, please
publish these patches somewhere.
I'll polish the quick hacks for libpthread and send it to the list.
Also, did you try some more complex programs?
Not yet. I'm looking for a prog
Quoting Marin Ramesa (2014-01-17 15:32:05)
> Function __atomic_load_n() is now used. Private futex structure and queue
> was defined to avoid conflicts in block and wakeup events. Now, private
> futex is really private and may only be used by threads of the task where
> it was locked.
>
> All of l
Function __atomic_load_n() is now used. Private futex structure and queue
was defined to avoid conflicts in block and wakeup events. Now, private
futex is really private and may only be used by threads of the task where
it was locked.
All of libpthread tests are successful with pthread mutex based
