In article <20160623183105.ga7...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Thu, Jun 23, 2016 at 01:56:33PM -0400, Christos Zoulas wrote:
>> On Jun 23, 7:26pm, jo...@bec.de (Joerg Sonnenberger) wrote:
>> -- Subject: Re: pthread library related
>>
>>
On Thu, Jun 23, 2016 at 01:56:33PM -0400, Christos Zoulas wrote:
> On Jun 23, 7:26pm, jo...@bec.de (Joerg Sonnenberger) wrote:
> -- Subject: Re: pthread library related
>
> | > Yes, but should we commit the proposed ENOSYS stubs in the meantime just
> | > to have the func
On Jun 23, 7:26pm, jo...@bec.de (Joerg Sonnenberger) wrote:
-- Subject: Re: pthread library related
| > Yes, but should we commit the proposed ENOSYS stubs in the meantime just
| > to have the functions available? I am not sure...
|
| No, that would do more harm than good.
I agree;
On Thu, Jun 23, 2016 at 03:33:08PM +, Christos Zoulas wrote:
> In article <20160520091545.ga30...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
> >On Thu, May 19, 2016 at 01:36:29PM -0400, Christos Zoulas wrote:
> >> You can see how FreeBSD is implementing them; it is a lot of code to do
>
In article <20160520091545.ga30...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Thu, May 19, 2016 at 01:36:29PM -0400, Christos Zoulas wrote:
>> You can see how FreeBSD is implementing them; it is a lot of code to do
>> this and would require some architectural review. The relevant files are
On Jun 2, 5:41pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
| If there are no comments for these two patches.
| I will move forward for other parts.
|
| Sounds good?
|
Have you created a github repository for the patches and one for
the changes to
gt;
>> Thanks Charles
>>
>> 2016-05-30 13:46 GMT-07:00 Christos Zoulas :
>>
>>> On May 30, 1:43pm, charles.cui1...@gmail.com (Charles Cui) wrote:
>>> -- Subject: Re: pthread library related
>>>
>>> | I am not familiar with _nv() (are t
ing cas.
> I will update the patch and send you guys later (being careful about the
> format)
>
> Thanks Charles
>
> 2016-05-30 13:46 GMT-07:00 Christos Zoulas :
>
>> On May 30, 1:43pm, charles.cui1...@gmail.com (Charles Cui) wrote:
>> -- Subject: Re: pthread libra
On Tue, May 31, 2016 at 04:49:00AM +0200, Steffen Nurpmeso wrote:
> Joerg Sonnenberger wrote:
> |On Mon, May 30, 2016 at 02:19:26PM -0700, Charles Cui wrote:
> |> good to know atomic_inc_uint_nv is implemented using cas.
> |
> |No, atomic_inc is *not* necessarily implemented using CAS. There a
Joerg Sonnenberger wrote:
|On Mon, May 30, 2016 at 02:19:26PM -0700, Charles Cui wrote:
|> good to know atomic_inc_uint_nv is implemented using cas.
|
|No, atomic_inc is *not* necessarily implemented using CAS. There are a
What a pity.
|couple of different ways to do it ranging from implici
On Mon, May 30, 2016 at 02:19:26PM -0700, Charles Cui wrote:
> good to know atomic_inc_uint_nv is implemented using cas.
No, atomic_inc is *not* necessarily implemented using CAS. There are a
couple of different ways to do it ranging from implicit serialisation on
UP-only systems over CAS/LL-SC lo
thread library related
>
> | I am not familiar with _nv() (are there examples in the netbsd code
> base? I
> | searched _nv() in nxr, but did not found anything meaningful.),
> | but if you want to use atomic operations, one possible way is
> | compare-and-swap (CAS).
> | it
I am not familiar with _nv() (are there examples in the netbsd code base? I
searched _nv() in nxr, but did not found anything meaningful.),
but if you want to use atomic operations, one possible way is
compare-and-swap (CAS).
it has stronger guarantee than atomic inc or atomic dec, but also larger
rtin Husemann) wrote:
> -- Subject: Re: pthread library related
>
> | Do we really need this? Why is it a function pointer?
>
> It is the same as signal.
>
> | > The third one is the missing kernel logic for _SC_SEM_NSEMS_MAX.
> |
> | Why not use atomic_inc/atomic_dec fo
Hi Kamil,
_SC_SEM_NSEMS_MAX is not the same with SEM_VALUE_MAX.
The first one is used to limit the number of sems for a process, while
the second is used to set the initial value for a semaphore.
2016-05-26 16:25 GMT-07:00 Kamil Rytarowski :
>
>
> On 27.05.2016 00:02, Christos Zoulas wrote:
>
On May 30, 1:43pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
| I am not familiar with _nv() (are there examples in the netbsd code base? I
| searched _nv() in nxr, but did not found anything meaningful.),
| but if you want to use atomic operations
On Mon, May 30, 2016 at 01:25:34PM -0700, Charles Cui wrote:
> there is one remaining slot. And each of them will increase p_nsem by one
> using atomic_inc, the results are we have 1 slot overused, but the error is
> never detected.
You will have to use a _nv() variant and use the return value to
the patch of the porting work shortly.
>
>
> 2016-05-26 15:02 GMT-07:00 Christos Zoulas :
>
>> On May 26, 2:08pm, charles.cui1...@gmail.com (Charles Cui) wrote:
>> -- Subject: Re: pthread library related
>>
>> 1. SIGRTMIN/SIGRTMAX should not be exposed (the kernel doe
On Mon, May 30, 2016 at 03:34:20PM -0400, Christos Zoulas wrote:
> It is not a function pointer; it is a function that takes as an argument
> the new signal handler (function pointer) returns a function
> pointer (the old signal handler function)
Duh, wrong paranthization - I'll shut up.
Martin
On May 30, 10:33am, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
The bsd_signal patch looks good!
christos
On May 30, 10:33am, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
Inline comments.
christos
diff --git a/lib/libpthread/pthread.h b/lib/libpthread/pthread.h
index 5970378..ed16d7c 100644
--- a/lib/libpthread/pthread.h
+++ b/lib/libpthread/pthread.h
On May 30, 10:33am, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
Looks good, but be careful with whitespace in general:
@@ -316,7 +316,7 @@ ksem_create(lwp_t *l, const char *name, ksem_t **ksret,
mode_t mode, u_int val)
if (val > SEM_VALUE_
On May 30, 9:32pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: pthread library related
| On Mon, May 30, 2016 at 03:28:09PM -0400, Christos Zoulas wrote:
| > On May 30, 8:29pm, mar...@duskware.de (Martin Husemann) wrote:
| > -- Subject: Re: pthread library related
| >
On Mon, May 30, 2016 at 03:28:09PM -0400, Christos Zoulas wrote:
> On May 30, 8:29pm, mar...@duskware.de (Martin Husemann) wrote:
> -- Subject: Re: pthread library related
>
> | Do we really need this? Why is it a function pointer?
>
> It is the same as signal.
OK. Why is &
On May 30, 8:29pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: pthread library related
| Do we really need this? Why is it a function pointer?
It is the same as signal.
| > The third one is the missing kernel logic for _SC_SEM_NSEMS_MAX.
|
| Why not use atomic_inc/atomic_
On Mon, May 30, 2016 at 10:33:33AM -0700, Charles Cui wrote:
> The second one is the reimplementation of bsd signal.
Do we really need this? Why is it a function pointer?
> The third one is the missing kernel logic for _SC_SEM_NSEMS_MAX.
Why not use atomic_inc/atomic_dec for the p_nsem count (a
Please see my comments inline.
2016-05-26 14:35 GMT-07:00 Christos Zoulas :
> On May 26, 2:08pm, charles.cui1...@gmail.com (Charles Cui) wrote:
> -- Subject: Re: pthread library related
>
> | Hi Christos,
> |
> |I am studying the pthread libraries in netbsd, and have
On 27.05.2016 00:02, Christos Zoulas wrote:
> 5. _SC_SEM_NSEMS_MAX, although that's not the real limit, good enough.
Is it the same (indirectly) SEM_VALUE_MAX?
#define SEM_VALUE_MAX (~0U)
It's located in .
I think we should go for LONG_MAX:
1. We will be able to return it via sysconf(3)
2.
On May 26, 3:27pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
| Yes, I can do 2 and 5, and fix 3.
| I am now in the progress of porting ad's patch, let's complete it.
| Once I have verified the porting part is done (compile new ke
l send you guys the patch of the porting work shortly.
2016-05-26 15:02 GMT-07:00 Christos Zoulas :
> On May 26, 2:08pm, charles.cui1...@gmail.com (Charles Cui) wrote:
> -- Subject: Re: pthread library related
>
> 1. SIGRTMIN/SIGRTMAX should not be exposed (the kernel does not support
On May 26, 3:05pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
| This is really helpful, actually, I searched _SC_TIMER_MAX and
| _POSIX_TIMER_MAX in nxr,
| but the results cannot indicate where these logics can be found.
| One more question, does other
On May 26, 2:08pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
1. SIGRTMIN/SIGRTMAX should not be exposed (the kernel does not support
the functionality).
2. I guess the bsd_signal is ok, but I don't like it :-)
http://pubs.opengrou
(Charles Cui) wrote:
> -- Subject: Re: pthread library related
>
> | Thanks Christos, Martin and SODA for these advices and documents!
> | I will start to get familiar with freebsd designs and try to contribute
> as
> | much
> | as possible to netbsd community.
>
> Hi Cha
On May 26, 2:08pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: Re: pthread library related
| Hi Christos,
|
|I am studying the pthread libraries in netbsd, and have several patches
| completed.
| I have attached all of them, which is pretty easy, but can fix some
| problems
On 20.05.2016 11:15, Joerg Sonnenberger wrote:
> On Thu, May 19, 2016 at 01:36:29PM -0400, Christos Zoulas wrote:
>> You can see how FreeBSD is implementing them; it is a lot of code to do
>> this and would require some architectural review. The relevant files are:
>>
>> http://nxr.netbsd.org/xref/
On Thu, May 19, 2016 at 01:36:29PM -0400, Christos Zoulas wrote:
> You can see how FreeBSD is implementing them; it is a lot of code to do
> this and would require some architectural review. The relevant files are:
>
> http://nxr.netbsd.org/xref/src-freebsd/lib/libthr/thread/thr_pshared.c
> http:/
ote:
> -- Subject: pthread library related
>
> | Hi guys,
> |
> |
> |I spent some time on pthread libraries in netbsd which is a big part
> in
> | my project, and have some questions to ask.
> | Taking pthread_barrierattr_getpshared, pthread_barrierattr_setpshared
> | as
Thanks Martin and Soda!
How about other functions? Does it make sense to follow POSIX standard
to implement the missing functions in netbsd?
2016-05-18 19:00 GMT-07:00 SODA Noriyuki :
> > On Thu, 19 May 2016 01:13:09 +0200,
> Martin Husemann said:
>
> > int pthread_barrierattr_setpshar
On May 18, 3:40pm, charles.cui1...@gmail.com (Charles Cui) wrote:
-- Subject: pthread library related
| Hi guys,
|
|
|I spent some time on pthread libraries in netbsd which is a big part in
| my project, and have some questions to ask.
| Taking pthread_barrierattr_getpshared
On May 19, 11:00am, s...@yuruyuru.net (SODA Noriyuki) wrote:
-- Subject: Re: pthread library related
| >>>>> On Thu, 19 May 2016 01:13:09 +0200,
| Martin Husemann said:
|
| > int pthread_barrierattr_setpshared(pthread_barrierattr_t *attr,
| >int pshared)
On Thu, May 19, 2016 at 06:06:19PM +0900, SODA Noriyuki wrote:
> Yes.
> Easiest way is to call a locking system call always, in the case of
> PTHREAD_PROCESS_SHARED.
Oh, didn't think of that - nice, and only hits the stupid shared case
(performance wise).
Martin
> On Thu, 19 May 2016 10:36:57 +0200,
Martin Husemann said:
>> Adding real implementation (instead of the ENOSYS stub) is desired,
>> of course...
> In this case: is it even possible in a portable way for all of our
> architectures?
Yes.
Easiest way is to call a locking system call
On Thu, May 19, 2016 at 12:49:07PM +0900, SODA Noriyuki wrote:
> Adding real implementation (instead of the ENOSYS stub) is desired,
> of course...
In this case: is it even possible in a portable way for all of our
architectures?
Martin
Forgot to say one thing...
> On Thu, 19 May 2016 12:44:57 +0900, SODA Noriyuki said:
>> How about other functions? Does it make sense to follow POSIX standard
>> to implement the missing functions in netbsd?
> In general, it's not recommended to add a stub function which returns
> ENOSYS (i
> On Wed, 18 May 2016 20:31:08 -0700,
Charles Cui said:
> How about other functions? Does it make sense to follow POSIX standard
> to implement the missing functions in netbsd?
In general, it's not recommended to add a stub function which returns
ENOSYS (i.e. "Function not implemente
> On Thu, 19 May 2016 01:13:09 +0200,
Martin Husemann said:
> int pthread_barrierattr_setpshared(pthread_barrierattr_t *attr,
>int pshared)
> {
> return EINVAL;
> }
I think the following is better:
int pthread_barrierattr_setpshared(pthread_barrierattr_t *attr,
i
On Wed, May 18, 2016 at 03:40:38PM -0700, Charles Cui wrote:
>*functions with missing features*:
>pthread_barrierattr_getpshared
>pthread_barrierattr_setpshared
Effectively:
int pthread_barrierattr_getpshared(const pthread_barrierattr_t
*restrict attr, int *restrict pshared)
{
Hi guys,
I spent some time on pthread libraries in netbsd which is a big part in
my project, and have some questions to ask.
Taking pthread_barrierattr_getpshared, pthread_barrierattr_setpshared
as an example. These functions are used to getting and setting barrierattr
data structure. netbsd
48 matches
Mail list logo
