Hi, Ross,
> On Dec 18, 2020, at 10:39, Ross Andrew Donnachie
> wrote:
>
> Is it possible that backend code that doesn't enclose its shared memory
> access (hput*() or hget*()) between hashpipe_status_un/lock_safe() would
> cause semaphore errors? This could be reasonably deduced as logical
Hi, Ross,
> On Dec 16, 2020, at 22:08, Ross Andrew Donnachie
> wrote:
>
> Been working on a hashpipe with a pipeline of network, transposition and then
> disk-dump threads. We have 24 data-buffers that we rotate through.
>
> An inconsistent (happens after various amounts of time) crash
Many thanks for your time and consideration Mark!
All of your above is knowledge I built up tackling the aftermath of these
crashes (when the shared memory becomes mangled). This current one occurs
while recording antenna data: the hashpipe either created clean shared
memory attached itself to
Last note, also do it before you set any parameters in shared memory (in
case you're doing so) otherwise they'll be cleared before you run hashpipe.
Mark Ruzindana
On Thu, Dec 17, 2020 at 3:37 PM Mark Ruzindana wrote:
> Just another note which is a little simpler. I haven't thought about this
Just another note which is a little simpler. I haven't thought about this
in a while because I wrote a python interface that runs the
hashpipe executable and performs a few other actions for me, but you might
also just need to clear the shared memory with the "hashpipe_clean_shmem -I
*instance
Hi Ross,
I think I have a solution to your problem. It's possible that it's
something else or you might need/want to solve it in a different way, but
this is how I do it.
The problem is most likely because shared memory segments and semaphore
arrays are being locked and when a change is made to
Good day all,
Been working on a hashpipe with a pipeline of network, transposition and
then disk-dump threads. We have 24 data-buffers that we rotate through.
An inconsistent (happens after various amounts of time) crash occurs with
this printout:
7 matches
Mail list logo
