| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
code did not compile after merge from v4
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
runtime/Makefile.am
runtime/atomic.h
runtime/queue.c
runtime/queue.h
runtime/wti.c
runtime/wti.h
runtime/wtp.c
runtime/wtp.h
|
| |
| |
| |
| |
| |
| | |
replaced atomic operation emulation with new code. The previous code
seemed to have some issue and also limited concurrency severely. The
whole atomic operation emulation has been rewritten.
|
| |
| |
| |
| | |
issues
|
| |
| |
| |
| |
| | |
... greater performance and was able to remove a potential troublespot
in a cancel cleanup handler.
|
| |
| |
| |
| |
| |
| | |
...if not running in direct mode. Previous versions could run without
any active workers. This simplifies the code at a very small expense.
See v5 compatibility note document for more in-depth discussion.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... could even remove one mutex by using a better algorithm. I think I also
spotted some situation in which a hang could have happened. As I can't fix it
in v4 and less without moving to the new engine, I make no effort in testing
this out. Hangs occur during shutdown, only (if at all). The code changes
should also result in some mild performance improvement. Some bug potential,
but overall the bug potential should have been greatly reduced.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
based on now working with detached threads. This is probably the biggest
patch in this series and with large bug potential.
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was a complex manual merge, especially in action.c. So if
there occur some problems, this would be a good point to start
troubleshooting. I run a couple of tests before commiting and
they all went well.
Conflicts:
action.c
action.h
runtime/queue.c
runtime/queue.h
runtime/wti.c
runtime/wti.h
|
| |
| |
| |
| |
| |
| | |
... as it was not even optimal on uniprocessors any longer ;) I keep
the config directive in, maybe we can utilize it again at some later
point in time (questionable).
|
| |
| |
| |
| | |
slightly improved situation, would like to save it before carrying on
|
| |
| |
| |
| | |
... now that we know what we need from a theoretical POV.
|
|/
|
|
|
|
| |
... but this code has serious problems when terminating the queue, also
it is far from being optimal. I will commit a series of patches (hopefully)
as I am on the path to the final implementation.
|
|
|
|
|
|
| |
...to enable users to turn off pthread_yield calls which are
counter-productive on multiprocessor machines (but have been
shown to be useful on uniprocessors)
|
|
|
|
|
|
|
|
| |
- changed sequence when awakening thread
- removed no longer needed condition variable
- EXPERIMENTALLY added mutex guarding to hostname lookups
this is to be removed if it does not have any verifyable
useful effect
|
|
|