fastevent calls SDL locking functions for thread safetly. I don't know
how this is superior to CPython's Global Interpreter Lock (GIL) which
automatically provides thread locking for extension module functions.
The only difference I can see is that fastevent.post() can wait when the
message queue is full, as it releases the GIL, while event.post() raises
an exception.
Lenard
Chris Smith wrote:
I'm not worried about events currently being 'slow'. But I would like
to know what the extra overhead would be.
If it's otherwise backwards compatible, I see no problem.
Chris
2008/12/1 Lenard Lindstrom <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
Hi René,
I don't know enough about fastevent to make a suggestion. It is
undocumented. I do see that "fast"event has more overhead than
event though.
Lenard
René Dudfield wrote:
hi,
I think we should change fastevents to be the default event
module... making the other event module 'oldevent'.
This is because fastevent is just nicer when using threads :)
- event (will be the fastevents module)
- fastevents (will be an alias to the new event module, which
is the fastevents module)
- oldevent (will be the current event module)
Any objections?
cheers,
ps. note, I've started using [dev] subject for pygame
development related threads.
--
Lenard Lindstrom
<[EMAIL PROTECTED]>