Hello fellow Racketeers,

my spare-time out-of-curiosity venture into using HPR (High-Performance Racket) for creating a software 3D rendering pipeline seems to be pushing the futures into rough edges.

The scenario is sort of "usual":

* 7 futures + 1 in RTT that form a binary tree
* GUI thread running

But this time, the futures perform not only data-heavy fixnums operations, but flonums operations as well.

Something along the lines of 2560x1440 fixnums and the same number of flonums is being handled in 8 threads effectively (give or take some optimizations that slightly lower the 1440 height usually).

The code in question is relatively short - say 60 lines of code - however it does not make much sense without the remaining 2k lines :)

If the operation runs without futures in RTT, nothing happens. But under a heavy load and VERY varying amount of time (seconds to hours), it completely freezes with:

* 1 CPU being used at 100% (top/htop shows)
* Does not handle socket operations (X11 WM message for closing the window)
* Does not respond to keyboard (or via kill) SIGINT
* Can only be forcibly stopped by SIGKILL (or similar) or forcefully closing the window from WM which sort of gets handled probably in the lower-level parts of GDK completely without Racket runtime intervention (just prints Killed and the exit code is 137)

Based on these observations I can only conclude that it is the RTT that gets stuck - but that is only the native thread perspective. From Racket thread perspective, it can be either the "main" application thread that is in (thread-wait) for the thread that performs the futures stuff and it can also be the GUI thread which is created with parameterizing the eventspace (that is just some trickery to allow me to send breaks when I receive window close event).

Apart from obvious strace (after freeze) and gdb (before/after freeze) debugging to find possible sources of this bug, is there even a remote possibility of getting any clue how can this happen based on the information gathered so far? My thought go along the lines:

* flonums are boxed - but for some operations they may be immediate
* apparently it is a busy-wait loop in RTT, otherwise 100% CPU usage is impossible with this workload * unsafe ops are always suspicious, but again, the problem shows up even when I switch to the safe versions - it just takes longer time
* which means, the most probable cause is a race condition

And that is basically all I can tell right now.

Of course, any suggestions would be really welcome.


P.S.: I am really curious, what will I find when I finally put fsemaphores into the mix...

You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to