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

Author Topic: sfml equivalent of GetMessage()  (Read 46342 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #15 on: November 01, 2008, 10:16:25 pm »
Because it adds complexity and decrease performances...
Laurent Gomila - SFML developer

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
sfml equivalent of GetMessage()
« Reply #16 on: November 01, 2008, 10:19:53 pm »
But on the other side you can't wait for crashes...
Want to play movies in your SFML application? Check out sfeMovie!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #17 on: November 01, 2008, 11:06:13 pm »
Hum... are you actually an expert in multi-threading, and posting relevant suggestions? Or just trying to guess some possible questions that might make sense? :P

I'm always opened (and happy) to discuss multi-threading stuff, but only if it makes sense. This is a complex but important part of this kind of libraries.
Laurent Gomila - SFML developer

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
sfml equivalent of GetMessage()
« Reply #18 on: November 01, 2008, 11:27:06 pm »
Waiting for crashes in order to fix the problems just does not seem to be a good idea to me.
Want to play movies in your SFML application? Check out sfeMovie!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #19 on: November 02, 2008, 09:44:11 am »
It's much more complex than just "is there a chance this line crashes in a multithread architecture ? ok, I put a mutex and that will be fine".

And, as far as I remember, there is no reported issue which is purely related to thread-safety in SFML so far.

But if you still think it's not enough, then I'll be glad to wait for your analysis regarding possible mutlithreading issues :)
Laurent Gomila - SFML developer

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
sfml equivalent of GetMessage()
« Reply #20 on: November 02, 2008, 11:28:36 am »
Hm.. yeah, as soon as I know a bit more about the topic :lol: .
Want to play movies in your SFML application? Check out sfeMovie!

kfriddile

  • Newbie
  • *
  • Posts: 12
    • View Profile
sfml equivalent of GetMessage()
« Reply #21 on: November 03, 2008, 04:52:41 am »
Quote from: "Laurent"

1/ I'm making a difference between using CPU and wasting CPU. Of course a function call uses CPU, but for sure doesn't waste it.


Using something when it doesn't need to be used is the definition of the word "waste".

Quote from: "Laurent"

2/ I'm talking about dependencies, not about performances. Libraries providing clean signal / slot features are just too big; the other solution is to wait for their integration into the C++ standard but it's not for now.


I never asked you to implement any kind of signal/slot or callback system.  I just asked for a blocking GetMessage() type call so I could implement my own.

Quote from: "Laurent"

3/ SFML must be 100% bindable to C. Signals / slots are not.


See response to 2 above.

Quote from: "Laurent"

I think SFML is appreciated because I care about beginners. Trust me. And believe me, thread safety is not beginner-friendly at all.


I think if you cared about beginners, you wouldn't hold them back with antiquated architecture.

Quote from: "Laurent"

5/ Regarding the memory leaks... it's a long story ;)


Yes, it was a long read.

Quote from: "Ceylo"

Is SFML supposed to be used for beginners only ? (I admit this would somewhat disapoint me)
I think the point is : do you prefer to focus on the library popularity or the library quality ?


Popularity and quality should be the same thing (unless one desires to only be popular among users who don't know any better...I wouldn't if it was my library).

Quote from: "Ceylo"

I've not thought of this for a long time, but whenever it would be easy for me to support blocking calls for events, that would also block display updates because I manually have to tell the OpenGL context when to swap the back and front buffers (which is done from the polling loop). Is this what you wish ?


If window events are that coupled to rendering (who says your current render-target has to be the back buffer?), then your architecture is flawed.  If such a blocking call existed, then it should be possible to call it on a separate thread than the one swapping the frame buffers.  There is no "polling loop" in that scenario.  "Polling" is akin to constantly asking the question "did anything happen yet?", while a rendering loop is constantly stating "draw this".

Quote from: "Laurent"

Ok, more details : the leak is indeed a small and controlled one, and its purpose is to enable a very important feature of SFML. Some people would even say it's not a leak; a leak is something which is not controlled and makes the memory consumption grow up and grow up. Actually, some implementations of STL or popular libraries can't free all the memory they use at program exit, and this is perfectly alright.


Your definition of "leak" is narrow-sighted.  A one-time allocation that is never freed is obviously a leak, and won't cause memory consumption to grow over time.  Leaks don't even have to refer to memory, since you can leak all kinds of other resources (device contexts, etc.)  Any STL implementation that leaks memory either isn't widely used or has been fixed to not leak memory.  It is ALWAYS possible for a program to free memory it has allocated.  Statements like saying memory leaks are "perfectly alright" are why I've decided not to use anything you've written.  There is absolutely no excuse for allowing any kind of resource leak.  I don't care if leaking one byte will allow your software to wash the dishes while creating world peace at the same time.  The idea of someone knowing about something as heinous as a leak and then rationalizing it instead of fixing it blows my mind.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #22 on: November 03, 2008, 09:19:50 am »
Quote
Using something when it doesn't need to be used is the definition of the word "waste".

Ok, fine for the definition. The point is, are we talking about the definition of "waste" or about the impact of such a design on SFML ? I don't think the main point between blocking wait and polling is to save or not a function call, it's much more a design issue. I think you'll agree with me, so let's not waste time with such considerations and focus on the design stuff ;)

Quote
I never asked you to implement any kind of signal/slot or callback system. I just asked for a blocking GetMessage() type call so I could implement my own.

You're right, sorry.

Quote
I think if you cared about beginners, you wouldn't hold them back with antiquated architecture.

You think not providing a blocking GetEvent is antiquated architecture ? I don't, but indeed I could easily add it. The only reason why I don't, is exactly why you want it : the only use I can see of such a function would be to implement an asynchronous signal / slot (or callback) system, and that's just idiot compared to the same system made synchronous. I agree it's less "elegant", but wasting a function call versus introducing multi-threading and all its potential issues... my choice is done. Imagine I just want to move a sprite in a keypress event, with your solution I would already have to care about concurrent accesses and go with mutexes to protect all accesses to my sprite. Not to talk about the fact that you could end up drawing your sprite in a different position than the one it had when you computed collisions / IA / ... in its update() function. That's just crazy, especially for beginners who are not be aware of all this stuff. And that costs much more than just polling.

Quote
Your definition of "leak" is narrow-sighted

That's wrong, YOUR definition is narrow-sighted. Mine is flexible and adapted to real situations, while yours is a "perfect world" definition. But we're not in a perfect world. Would you sacrifice an important feature of your library for the sake of "perfection" ?
Of course if you can tell me how to free this memory while keeping the feature, it would be great ;)

It's too bad we're fighting rather than trying to find solutions. It might not be obvious to you, but clean and well-designed code is one of my main goals too, I'm not that kind of programmer who just writes "code that works". So if you're ok I'd be really glad to talk more about the benefits and drawbacks of multithreaded event handling, and see what has or not to be added to SFML.
Laurent Gomila - SFML developer

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
sfml equivalent of GetMessage()
« Reply #23 on: November 03, 2008, 01:23:36 pm »
Quote from: "kfriddile"
Popularity and quality should be the same thing (unless one desires to only be popular among users who don't know any better...I wouldn't if it was my library).

Nop, because it you care about everyone, you won't force users to take care of thread safeness (that may indeed improve performances).


Quote from: "kfriddile"
If window events are that coupled to rendering (who says your current render-target has to be the back buffer?), then your architecture is flawed.  If such a blocking call existed, then it should be possible to call it on a separate thread than the one swapping the frame buffers.  There is no "polling loop" in that scenario.  "Polling" is akin to constantly asking the question "did anything happen yet?", while a rendering loop is constantly stating "draw this".


Okay. I was only thinking of the common event and drawing loop :
Code: [Select]

while(running) {
    // get all events
    // draw
}

This would prevent from drawing if you use blocking events.
Now... I do not know enough about multi-threading issues to tell whether you can safely call for buffer swaping from a separate thread.


Quote from: "kfriddile"
[...]  It is ALWAYS possible for a program to free memory it has allocated.  [...]

But what for ? If it was to be freed, it would be just before the program exits. Therefore it is useless.
Want to play movies in your SFML application? Check out sfeMovie!

bullno1

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
sfml equivalent of GetMessage()
« Reply #24 on: November 03, 2008, 01:48:11 pm »
Quote
Your definition of "leak" is narrow-sighted.

If I'm not wrong, modern OSes can free the all memory that a program uses after it exits and even after it crashes. Memory leaks only matters if it grows memory consumption over time. It may be a leak, but it's harmless if it's just a one-time leak. Moreover, while RAM is getting cheaper and people's average age decreases, why should you waste your precious life in such thing?

Btw, where's the leak that you two are talking about? I might try to look into it.

About the blocking thing, IMO, you can consider creating 2 version of the function(one polling and one blocking). I did not look into the implementation and I'm also linux and mac-impaired so I don't know if it's possible to handle event in such ways. Just my 2 cents.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #25 on: November 03, 2008, 02:27:16 pm »
Quote
Btw, where's the leak that you two are talking about? I might try to look into it.

There's a global context created in sfml-window's Context class (in current sources, not 1.3), which can never be destroyed because it may be used until the very last instruction of the program. The trickiest issue requiring this kind of stuff is probably the .Net binding, because the GC can still run and free resources needing a context after the main thread has ended.

Quote
About the blocking thing, IMO, you can consider creating 2 version of the function(one polling and one blocking)

Technically, there's absolutely no problem for the 3 OSes SFML is supporting. It's really just a design question.
Laurent Gomila - SFML developer

kfriddile

  • Newbie
  • *
  • Posts: 12
    • View Profile
sfml equivalent of GetMessage()
« Reply #26 on: November 03, 2008, 05:52:09 pm »
Ok, at this point I'm losing interest in the original feature request of this thread.  I'm starting to feel a moral obligation to set you guys straight about resource leaks.  This is the first time I have EVER heard ANYONE say a resource leak is "ok".  This is software 101 people.  Any competent C/C++ programmer will tell you that resource leaks are right up there with crashes on the bug scale.

Quote from: "Ceylo"

Quote from: "kfriddile"
[...]  It is ALWAYS possible for a program to free memory it has allocated.  [...]

But what for ? If it was to be freed, it would be just before the program exits. Therefore it is useless.


It is in no way "useless".  First of all, there is absolutely no gaurantee that the operating system will clean up your mess (show me in the C++ standard where it says it will and I'll buy you each a car).  If there was, you wouldn't see languages like Java implementing automatic garbage collection.  Second, you may need that memory back BEFORE the program exits.  This is especially true of a middleware product like sfml where you can't anticipate the resource needs of the user.

Quote from: "Ceylo"

If I'm not wrong, modern OSes can free the all memory that a program uses after it exits and even after it crashes. Memory leaks only matters if it grows memory consumption over time. It may be a leak, but it's harmless if it's just a one-time leak. Moreover, while RAM is getting cheaper and people's average age decreases, why should you waste your precious life in such thing?


IF an OS frees resources leaked by a program, it does so as a fail-safe in case of programmer error, not something to be relied upon.  What you just said is the same thing as a pilot saying he can just jump out of his plane instead of landing it safely because his parachute will keep him from falling to his death.

Quote from: "Laurent"

Ok, fine for the definition. The point is, are we talking about the definition of "waste" or about the impact of such a design on SFML ? I don't think the main point between blocking wait and polling is to save or not a function call, it's much more a design issue. I think you'll agree with me, so let's not waste time with such considerations and focus on the design stuff Wink


It's both a design and efficiency issue (they are almost always intertwined).  Simply put, my design proposition allows for a more efficient program because it doesn't needlessly gobble up CPU cycles.

Quote from: "Laurent"

You think not providing a blocking GetEvent is antiquated architecture ? I don't, but indeed I could easily add it. The only reason why I don't, is exactly why you want it : the only use I can see of such a function would be to implement an asynchronous signal / slot (or callback) system, and that's just idiot compared to the same system made synchronous. I agree it's less "elegant", but wasting a function call versus introducing multi-threading and all its potential issues... my choice is done. Imagine I just want to move a sprite in a keypress event, with your solution I would already have to care about concurrent accesses and go with mutexes to protect all accesses to my sprite. Not to talk about the fact that you could end up drawing your sprite in a different position than the one it had when you computed collisions / IA / ... in its update() function. That's just crazy, especially for beginners who are not be aware of all this stuff. And that costs much more than just polling.


Yes, I do think it's antiquated.  So does Microsoft, so does Intel, etc.  "Elegant" design and robustness/efficiency go hand in hand.  For example, coupling with the rest of the app is greatly reduced when the "Window" object is capable of waiting for events itself without dictating the rest of the program's architecture.  Communication purely through callbacks is about as low as coupling gets.  Reduced coupling means more flexibility, reusability, and testability.  Anyways, about your sprite example...there are no concurrency issues involved.  It's just a simple example of the consumer/producer idiom.  There is one producer (the thread pumping the messages) and 0-N consumers.  It's not exactly how I would do it, but the simplest example would be to store key-pressed events in a bool array as 'true' and key-releases as 'false'.  That array would obviously have only one writer and 0-N readers (a sprite for example) so there are no concurrency issues whatsoever.

Quote from: "Laurent"

That's wrong, YOUR definition is narrow-sighted. Mine is flexible and adapted to real situations, while yours is a "perfect world" definition. But we're not in a perfect world. Would you sacrifice an important feature of your library for the sake of "perfection" ?
Of course if you can tell me how to free this memory while keeping the feature, it would be great Wink


Definitions are, by definition (har har), inflexible.  If we were allowed to bend definitions at our will to make things more convienent for us, they would be useless as identifiers for ideas (which is what they are supposed to be).  If I was writing a library to be used as black-box middleware by trusting users, then yes, I would ensure to the best of my abilities that no bugs, such as resource leaks, exist.  I think my coworker offered some suggestions to plug the leak in your email conversation with him, but, at the very worst, could it not be plugged inside an atexit callback?  I shudder to suggest such a hack, but it's far better than the leak.

Quote from: "Laurent"

It's too bad we're fighting rather than trying to find solutions. It might not be obvious to you, but clean and well-designed code is one of my main goals too, I'm not that kind of programmer who just writes "code that works". So if you're ok I'd be really glad to talk more about the benefits and drawbacks of multithreaded event handling, and see what has or not to be added to SFML.


I don't feel like we're fighting since nothing off-topic or personal has been said.  I'm just not the type to acquiesce when I know I'm right.  I get the impression that you view "elegant", "perfect" designs and code as things that are done for fun because one enjoys programming, and that compromises against those ideals are ok when working on an assignment or some other, more practical, software project.  I (and many others) think that mentality is exactly opposite of the truth.  When working on some prototypical peice of code, it's acceptable to hack and kludge a little bit, because the purpose of such code is just to prove that the problem is solvable.  It may not be.  Once the problem is known to be solvable, and it comes time to solve it in a production environment, it's now time to find the OPTIMAL solution to the problem.  By "optimal", I mean the best design, taking into account things like coupling with other components, flexibility, portability, future viability, and performance.

Wizzard

  • Full Member
  • ***
  • Posts: 213
    • View Profile
sfml equivalent of GetMessage()
« Reply #27 on: November 03, 2008, 07:36:28 pm »
Is it really a memory leak if the leak is being collected in all the supported operating systems? Not to mention that if it was actually leaking, it is only a couple hundred bytes. On even the oldest computers, that are still being used today for multimedia, you'd have to run the program over a trillion times for that much memory to begin to affect the computer in a noticeable way. It's not like the memory leak is in a loop or anything. Besides, Laurent wouldn't have intentionally put a memory leak into SFML unless it was simplifying the implementation and API greatly. So overall, I don't mind that my debugger says that I have a memory leak.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
sfml equivalent of GetMessage()
« Reply #28 on: November 03, 2008, 07:58:42 pm »
Quote from: "kfriddile"
First of all, there is absolutely no gaurantee that the operating system will clean up your mess (show me in the C++ standard where it says it will and I'll buy you each a car).

Yes there is, for any modern operating system. And it does not depends on a programming language.


Quote from: "kfriddile"
If there was, you wouldn't see languages like Java implementing automatic garbage collection.

Except if it was to allow lazy programmers not to take care of memory handling.

Quote from: "kfriddile"
What you just said is the same thing as a pilot saying he can just jump out of his plane instead of landing it safely because his parachute will keep him from falling to his death.

But here there is no plane crashing :].

Quote from: "kfriddile"
Definitions are, by definition (har har), inflexible.

But interpretations are not. That is the point here.
You have your way of seeing the things, which does not always mean it is the good one.

Quote from: "kfriddile"
I don't feel like we're fighting since nothing off-topic or personal has been said.  I'm just not the type to acquiesce when I know I'm right.

Lol :D . *sorry for the useless comment*
Want to play movies in your SFML application? Check out sfeMovie!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
sfml equivalent of GetMessage()
« Reply #29 on: November 03, 2008, 10:08:42 pm »
Quote
but, at the very worst, could it not be plugged inside an atexit callback?

I'm not sure it would work in every situation (like, as I said, in the C# binding where the main thread terminates before resources are freed), but I've found some good articles about global destruction in "Modern C++ design", I'll take a look at it.

Quote
It's not exactly how I would do it, but the simplest example would be to store key-pressed events in a bool array as 'true' and key-releases as 'false'. That array would obviously have only one writer and 0-N readers (a sprite for example) so there are no concurrency issues whatsoever

And then what ? Polling the array of booleans ? ... I really don't get it.
My point is that operations in a real-time program (not to say a game) have to be sequential (you can't move an entity while computing its collisions or drawing it, it has to be done at a specific place in the game loop). Decoupling event handling from the rest of the application just breaks this rule. I'm really curious to see how you would write a robust game architecture with multithreaded event handling and no polling.
Laurent Gomila - SFML developer