Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML concurrency vs C++ standard  (Read 5010 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • Moderator
  • Hero Member
  • *****
  • Posts: 9658
    • View Profile
    • development blog
    • Email
SFML concurrency vs C++ standard
« on: March 13, 2017, 08:54:15 pm »
Info & Rules about this sub-forum

One of the bigger changes with C++11 was the introduction of concurrency classes.
In the past SFML had no choice but to create its own abstraction for threads, mutexes and locks. But with C++11 these classes are basically just duplicated.

Similar to the sf::Time & sf::Clock discussion, the questions are:
  • Do we completely remove the SFML concurrency classes?
  • Or do we keep the API but change the implementation.
  • What are your arguments for either situation?
  • Do you have any concerns about standard concurrency classes?
Here are two simple examples again for SFML and C++11. Let us know if you think there's a better example to show case the differences or if some important difference was left out.

(click to show/hide)

(click to show/hide)

Summary
There doesn't seem to be a reason to keep the SFML API as the standard API does provide the same functionalities.
« Last Edit: March 23, 2017, 11:04:22 am by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

sjaustirni

  • Jr. Member
  • **
  • Posts: 95
    • View Profile
Re: SFML concurrency vs C++ standard
« Reply #1 on: March 13, 2017, 09:27:00 pm »
I think that in this case the Facade API by SFML doesn't bring any simplification to the client code and should not be kept in the library, as opposed to the aforementioned std::chrono vs sf::Clock/sf::Time.

DeathRay2K

  • Newbie
  • *
  • Posts: 24
    • View Profile
    • Email
Re: SFML concurrency vs C++ standard
« Reply #2 on: March 13, 2017, 09:46:01 pm »
I think keeping the SFML threads is worse than redundant, as they could discourage use of other new threading features like futures and async.

Hapax

  • Hero Member
  • *****
  • Posts: 3026
  • My number of posts is shown in hexadecimal.
    • View Profile
Re: SFML concurrency vs C++ standard
« Reply #3 on: March 13, 2017, 10:01:20 pm »
One option put forward is to implement std::thread under sf::Thread; this would likely include those features you mentioned. It wouldn't just be keeping the current sf::Thread and ignoring what std::thread can do.

However, there seems to be no need to wrap this if the wrapper is going to do the same thing with the same interface.

Standard threads (and locks etc.) should be sufficient.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

Turbine

  • Full Member
  • ***
  • Posts: 102
    • View Profile
Re: SFML concurrency vs C++ standard
« Reply #4 on: March 14, 2017, 04:00:53 am »
+1 for removing threads and also making SFML depend on C++11.

DarkRoku12

  • Full Member
  • ***
  • Posts: 203
  • Lua coder.
    • View Profile
    • Email
Re: SFML concurrency vs C++ standard
« Reply #5 on: March 14, 2017, 06:11:47 am »
I think that in this case the Facade API by SFML doesn't bring any simplification to the client code and should not be kept in the library, as opposed to the aforementioned std::chrono vs sf::Clock/sf::Time.

+1.  :)

Nothing more to say.
I would like a spanish/latin community...
Problems building for Android? Look here

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32418
    • View Profile
    • SFML's website
    • Email
Re: SFML concurrency vs C++ standard
« Reply #6 on: March 14, 2017, 06:28:49 am »
I think it's pretty obvious. sf::Thread, sf::Mutex, sf::Lock, sf::ThreadLocal, sf::ThreadLocalPtr and sf::sleep should all go away.
Laurent Gomila - SFML developer

Balnian

  • Newbie
  • *
  • Posts: 22
    • View Profile
Re: SFML concurrency vs C++ standard
« Reply #7 on: March 16, 2017, 07:20:58 pm »
I think it's pretty obvious. sf::Thread, sf::Mutex, sf::Lock, sf::ThreadLocal, sf::ThreadLocalPtr and sf::sleep should all go away.
I agree on this, full support from me on this one Laurent
But we could still provide helpers that use std for complex operations like sf::LockAll(std::mutex ... mutexs) // note this is an exemple to help see what i mean and std::lock does exactly this

Hiura

  • Moderator
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: SFML concurrency vs C++ standard
« Reply #8 on: March 17, 2017, 09:59:54 am »
But we could still provide helpers that use std for complex operations like sf::LockAll(std::mutex ... mutexs) // note this is an exemple to help see what i mean and std::lock does exactly this

This particular example will/is supported in C++17 if I'm correct. I guess we can always discuss about other specific helpers, but in general I'd avoid doing this: unless SFML needs it for some internal implementation, we'd rather not expose some threading API -- it's a topic that is complex enough to be solved by dedicated libraries while not having that much to do with multimedia, IMO.
SFML / OS X developer

JayhawkZombie

  • Jr. Member
  • **
  • Posts: 76
    • View Profile
Re: SFML concurrency vs C++ standard
« Reply #9 on: March 17, 2017, 04:38:41 pm »
I think it's pretty obvious. sf::Thread, sf::Mutex, sf::Lock, sf::ThreadLocal, sf::ThreadLocalPtr and sf::sleep should all go away.

Agreed.  The C++ interface is just as clean, and code would more cleanly tie in with the rest of the C++ threading libraries.
http://en.cppreference.com/w/cpp/thread
(I think cppreference isn't always easy to follow, and I prefer cplusplus.com - http://www.cplusplus.com/reference/multithreading/)

This particular example will/is supported in C++17 if I'm correct.
Correct, std::lock is variadic, and from what I can tell should already be supported in C++11 (so long as your compiler supports it): http://www.cplusplus.com/reference/mutex/lock/ 
If C++ implements a helper, I don't see any reason for SFML to wrap/re-implement it.  If not, perhaps SFML could provide a list of helpers for things, but there are libraries out there, like Hiura said, that are meant for exactly that.

Tank

  • Moderator
  • Hero Member
  • *****
  • Posts: 1481
    • View Profile
    • Blog
    • Email
Re: SFML concurrency vs C++ standard
« Reply #10 on: March 22, 2017, 10:35:22 pm »
Yup, drop 'em.

roccio

  • Jr. Member
  • **
  • Posts: 59
    • View Profile
    • Email
Re: SFML concurrency vs C++ standard
« Reply #11 on: March 23, 2017, 09:40:07 pm »
For me it's better to remove the sfml ones and just use std

Nexus

  • Moderator
  • Hero Member
  • *****
  • Posts: 6225
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML concurrency vs C++ standard
« Reply #12 on: March 26, 2017, 02:45:56 pm »
Definitely remove SFML ones. It helps people learn only one instead of two APIs -- the standard API, which can also be used outside SFML.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book