[PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Marin Ramesa
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

Re: [PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Justus Winter
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

Re: [PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Marin Ramesa
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

System Calls on Hurd

2014-01-17 Thread Subhashish Pradhan
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

Re: Fwd: System Calls on Hurd

2014-01-17 Thread Samuel Thibault
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

Re: [PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Diego Nieto Cid
El ene 17, 2014 11:36 a.m., Marin Ramesa m...@hi.t-com.hr 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; +

Re: [PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Samuel Thibault
Diego Nieto Cid, le Fri 17 Jan 2014 22:49:25 -0200, a écrit : El ene 17, 2014 11:36 a.m., Marin Ramesa m...@hi.t-com.hr 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

Re: [PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Richard Braun
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 m...@hi.t-com.hr escribió: + +kern_return_t +futex_wait(task_t task, vm_offset_t futex_address, int value, +        

Re: [PATCH v16] kern: simple futex for gnumach

2014-01-17 Thread Roland McGrath
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