We can simplify and universalize the logic here by acknowledging that
assemblyCycleComplete() will always destroy the current eventfdDesc
object, so we can just check that to see whether we should continue
the assembly cycle.
* PcloudStimulusProducer now has member sh_ptr<StimulusBuffer>s.
* StimulusProducer now has a vector<sh_ptr<StimulusBuffer>s.
Created new stimbuff-type-specific
Pcloud[Xyz|I|Ambience]StimulusBuffer classes for representing each
stim feature exposed by livoxGen1's PcloudStimulusProducer.
Doing it this way enables us to get the mapBuffer() call working
during finalize. But we couldn't get the unmap call working. That
has to do with a bug in the Rusticl event waiting code.
For some reason, waiting on the event object returned by
clEnqueueUnmapMemObject, but only when called from within finalize().
Under normal operating conditions when we map and then unmap our
HOST_PTR buffers, everything works just fine.
I can't discern any relevant difference.
Adding a bridged 300ms delay in setup() doesn't help either so it
doesn't seem to be solved by allowing the rusticl worker threads
to finish initializing.
GDB output from the segfault appended. Sadly, no debug symbols for
the ubuntu rusticl package.
```
[New Thread 0xffffdd2ce140 (LWP 1056313)]
validateOpenClVersion: OpenCL platform version: OpenCL 3.0
validateOpenClVersion: OpenCL device version: OpenCL 3.0
[New Thread 0xffffdcabe140 (LWP 1056314)]
[New Thread 0xffffc9a8f140 (LWP 1056315)]
start: Starting stimulus buffer for device 3JEDK380010Z39
attachDeviceReq3: Got return mode (0) for device: 3JEDK380010Z39
discardHeartbeatAck: Lidar not ready for operation: work_state: 0x0 (Initializing), ack_msg: 0x1b
discardHeartbeatAck: Lidar not ready for operation: work_state: 0x0 (Initializing), ack_msg: 0x45
discardHeartbeatAck: Lidar not ready for operation: work_state: 0x0 (Initializing), ack_msg: 0x45
discardHeartbeatAck: Lidar not ready for operation: work_state: 0x0 (Initializing), ack_msg: 0x45
attachDeviceReq5: Failed to enable pcloud data for dev 3JEDK380010Z39
newDeviceAttachmentSpecInd2: Attach failed for device spec Device Identifier: avia0, Sensor Type: e, QualeIface API: structural-qualeiface, QualeIface API Params: (), StimBuff API: livoxGen1, StimBuff API Params: (), Provider: livoxProto1, Provider Params: (smo-ip=10.42.0.2 ), Device Selector: 3JEDK380010Z39
attachAllUnattachedDevicesFromReq2: Failed to attach device: avia0
Mrntt: attached 0 of 2 sense devices.
Mrntt: Body component initialized.
initializeReq2: Failed to initialize globalMind
marionetteInitializeReqCb: Failed to initialize Marionette. Shutting down.
Mrntt: About to detach all sense devices.
Mrntt: Successfully detached 0 of 0 sense devices.
Mrntt: About to finalize all stim buff api libs.
compactKernelCompletecalling w/mapFlags=4. INV=4; READ=1.
mapBuffer 1
mapBuffer 2
mapBuffer 3: cmdQ: 0xffffec013d68, buffer: 0xffffec07b6b8, mapflags: 4
mapBuffer 4
mapBuffer 5
unmapBuffer 1
unmapBuffer 2
unmapBuffer 3
unmapBuffer 4
unmapBuffer 4.1
unmapBuffer 5
Thread 9 "rusticl queue t" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xffffdcabe140 (LWP 1056314)]
Download failed: Invalid argument. Continuing without source file ./string/../sysdeps/aarch64/multiarch/../memcpy.S.
__memcpy_generic () at ../sysdeps/aarch64/multiarch/../memcpy.S:155
warning: 155 ../sysdeps/aarch64/multiarch/../memcpy.S: No such file or directory
(gdb)
(gdb) bt
(gdb)
```
This makes the stop() method capable of synchronously stopping all
engine/server-type async services which don't act in a self-moved
fashion but instead wait for a request.
We've reworked the synchronous control functions that govern the
async daemon and in-flight requests for this class. The
shouldAcceptRequests flag represents the readiness state of the
whole engine class. The in-flight async operations consult the
shouldAcceptRequests flag to determine whether they should return
early.
Now the stop() method is solely for setting the locked flag
shouldAcceptRequests=false.
The pair resetAndAssembleFrame()/assemblyCycleComplete manage the
per-assembly cycle state machine, and they don't need to set or
interfere with the shouldAcceptRequests flag.
Placing these functions in the public section kind of conceptually
confuses the reader since start/stop are indeed public interface
members in StimulusBuffer -- but they're not in the member objects.
Although I don't think they're good for our project. We don't care
to map our standpoint to some external point/"frame". SMO retains
the FPoV without any external reference point.
There's a bug in the Rusticl implementation of clEnqueueMapBuffer/
clEnqueueUnmapMemObject because karolherbst doesn't understand
how CL_MEM_USE_HOST_PTR works.
When mapping in the collationBuff we only need to supply CL_MAP_WRITE
and not CL_MAP_WRITE_INVALIDATE_REGION since we don't care to
preserve the contents of the collation buff as input to the
collation kernel.
hayodea
latentprion