Send hpx-devel mailing list submissions to
        hpx-devel@stellar.cct.lsu.edu

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel
or, via email, send a message with subject or body 'help' to
        hpx-devel-requ...@stellar.cct.lsu.edu

You can reach the person managing the list at
        hpx-devel-ow...@stellar.cct.lsu.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of hpx-devel digest..."


Today's Topics:

   1. Re: Use of libcds code in HPX? (John Biddiscombe)
   2. Re: Use of libcds code in HPX? (Max Khizhinsky)


----------------------------------------------------------------------

Message: 1
Date: Sun, 18 Feb 2018 23:18:43 +0100
From: John Biddiscombe <biddi...@cscs.ch>
Subject: Re: [hpx-devel] Use of libcds code in HPX?
To: Max Khizhinsky <libcds....@gmail.com>
Cc: hpx-devel@stellar.cct.lsu.edu
Message-ID: <a5fbf399-0bf6-216e-3c1b-6a69864c1...@cscs.ch>
Content-Type: text/plain; charset="utf-8"

Max (CC'd to hpx-dev list)

 > Yes, of course, I can change license of libcds from BSD to boost, no 
problem.

Wow! this is great news indeed - thank you so much. This is a great 
opportunity for HPX to benefit from your work.

We'll have to think about how we proceed from here - whether we

 ??? a) use selected bits of libcds in an hpx::concurrent namespace

 ??? b) use the whole of libcds as a subproject of hpx and put 
everything into an hpx::concurrent namespace or even hpx::libcds 
namaespace (to make it clear where stuff is coming from).

As I alluded to in my initial email, we'll want to spend some time 
looking into libcds and seeing how much can be reused directly, and how 
much needs to be massaged to use hpx types so that things can be 
integrated cleanly without too much duplication - there probably a lot 
of overlap in hpx/libcds for some of the utility type tools and low 
level detail, so forking libcds and making an hpx specific version seems 
like the way to go at first.

Since we have a potential GSoC student prepared to work on this over the 
summer, it would be great to give him this task and see how far we get 
(it might be too much for a summer student, but we have several devs who 
are mentors and would help out - if you would like to be involved, just 
ask).
Hopefully, other hpx devs will chime in on the list with ideas and we'll 
start making plans.

Thanks again - I'm sure I speak for all the HPX developers when I say 
that this is great news and we really appreciate it.

JB



On 02/18/2018 11:30 AM, Max Khizhinsky wrote:
> Hi John,
>
>> Is there any way that you would consider re-licensing any/all of 
>> libcds under the boost license?
>
> Yes, of course, I can change license of libcds from BSD to boost, no 
> perhars problem.
>
> I would be very happy to participate in such an excellent project as 
> HPX and integrate HPX with libcds or its part. I think with common 
> effort we can make both projects more useful.
>
> Best regards,
> ??? Max Khizhinsky
>
> 16.02.2018 0:43, John Biddiscombe ?????:
>> Dear Maxim/libcds developers
>>
>> I am writing to ask about the license of libcds - it's a permissive 
>> license which is great, but ...
>>
>> Within the HPX project (https://github.com/STEllAR-GROUP/hpx ) we are 
>> in need of some more lockfree containers and data structures and we'd 
>> really like to use some of libcds - however, HPX is licensed under 
>> the boost license.
>> The main difference between the boost and BSD licenses from what I 
>> can see is that the boost license does not require *binaries* making 
>> use of it to include the copyright text, so people can use HPX 
>> without any kind of attribution or copyright reference in their 
>> distributed applications.
>>
>> Is there any way that you would consider re-licensing any/all of 
>> libcds under the boost license?
>>
>> [We would need to make some changes to the code due to the way HPX 
>> locks/lightweight threads operate, but hopefully much could be reused 
>> with without fundamental changes (and we would ideally try to find a 
>> way to do it so that future updates from libcds or fixes from hpx 
>> developers could be propagated both ways) - we have a potential 
>> Google summer of code student who would like to work on concurrent 
>> data structures and it is because of this that I am writing this 
>> email - we have watched the development of libcds over the last few 
>> years and have lamented the fact that we can't use such a great 
>> project ourselves due to the license issues. (NB. I have attached 
>> anexample of how we have done this in the past at the end of this 
>> email).
>>
>> If there is any way we can use libcds code in HPX, we would be very 
>> grateful hearing from you and will happily take any suggestions on 
>> how to proceed.
>>
>> Many Thanks
>>
>> John Biddiscombe (on behalf of HPX)
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mail.cct.lsu.edu/pipermail/hpx-devel/attachments/20180218/a5279ed4/attachment-0001.html
 

------------------------------

Message: 2
Date: Mon, 19 Feb 2018 12:26:04 +0300
From: Max Khizhinsky <libcds....@gmail.com>
Subject: Re: [hpx-devel] Use of libcds code in HPX?
To: John Biddiscombe <biddi...@cscs.ch>
Cc: hpx-devel@stellar.cct.lsu.edu
Message-ID: <5932f591-a9e8-2cb0-a312-c693d12aa...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi John (and HPX community),

> ??? a) use selected bits of libcds in an hpx::concurrent namespace
>
> ??? b) use the whole of libcds as a subproject of hpx and put 
> everything into an hpx::concurrent namespace or even hpx::libcds 
> namaespace (to make it clear where stuff is coming from).
I think, option b) is the best. For me, the name of namespace is not so 
important, we should follow the stuff accepted in HPX.

> As I alluded to in my initial email, we'll want to spend some time 
> looking into libcds and seeing how much can be reused directly, and 
> how much needs to be massaged to use hpx types so that things can be 
> integrated cleanly without too much duplication - there probably a lot 
> of overlap in hpx/libcds for some of the utility type tools and low 
> level detail, so forking libcds and making an hpx specific version 
> seems like the way to go at first.
Yes, I must study HPX project/infrastructure too.

In outline, the main part of libcds is safe memory reclamation (SMR) 
schemas - Hazard Pointer (HP), user-space RCU and its variations. I 
think, they should be integrated first. As I know, there are C++ 
proposals about HP/RCU standartization in STL, maybe, we should take in 
consideration these papers right now and implement them during 
integration phase.? After that, all (or part of) libcds containers can 
be moved to HPX. The interface of containers can be reviewed/rethink, 
I'm open for any questions/suggestions.

BR

 ??? Max Khizhinsky


19.02.2018 1:18, John Biddiscombe ?????:
>
> Max (CC'd to hpx-dev list)
>
> > Yes, of course, I can change license of libcds from BSD to boost, no 
> problem.
>
> Wow! this is great news indeed - thank you so much. This is a great 
> opportunity for HPX to benefit from your work.
>
> We'll have to think about how we proceed from here - whether we
>
> ??? a) use selected bits of libcds in an hpx::concurrent namespace
>
> ??? b) use the whole of libcds as a subproject of hpx and put 
> everything into an hpx::concurrent namespace or even hpx::libcds 
> namaespace (to make it clear where stuff is coming from).
>
> As I alluded to in my initial email, we'll want to spend some time 
> looking into libcds and seeing how much can be reused directly, and 
> how much needs to be massaged to use hpx types so that things can be 
> integrated cleanly without too much duplication - there probably a lot 
> of overlap in hpx/libcds for some of the utility type tools and low 
> level detail, so forking libcds and making an hpx specific version 
> seems like the way to go at first.
>
> Since we have a potential GSoC student prepared to work on this over 
> the summer, it would be great to give him this task and see how far we 
> get (it might be too much for a summer student, but we have several 
> devs who are mentors and would help out - if you would like to be 
> involved, just ask).
> Hopefully, other hpx devs will chime in on the list with ideas and 
> we'll start making plans.
>
> Thanks again - I'm sure I speak for all the HPX developers when I say 
> that this is great news and we really appreciate it.
>
> JB
>
>



------------------------------

_______________________________________________
hpx-devel mailing list
hpx-devel@stellar.cct.lsu.edu
https://mail.cct.lsu.edu/mailman/listinfo/hpx-devel


End of hpx-devel Digest, Vol 37, Issue 2
****************************************

Reply via email to