Re: [Simulavr-devel] GDB to stdin connection & threading

[Petr Hluzín]

On 29 January 2012 21:01, David Madden <address@hidden> wrote:
> On 1/29/2012 11:54, Petr Hluzín wrote:
>>
>> all communication-capable classes would put
>> event objects (Windows) or file descriptors (Unixes) to a central
>> location which would do WaitForMultipleObjects() or select() on them.
>
>
> It's been a long (LONG!) time since I did this stuff, but IIRC, that was the
> best option I could come up with back in the day.  Windows and Unix are
> different in an inconvenient way right here (although the Windows model
> works fine, more or less; it's really not as stupid as my younger self
> thought it was!)
>
> If you run communications through a central thread as you propose, you can
> get the semantics you want relatively easily on either platform. (The
> downside is code tweaking that may happen in a lot of places.)

Actually no, the auxiliary thread would be only used for the pipe from
GDB (and only on Windows). The thread would set an event object, which
will be waited on by the main thread. The main thread will wait on
event objects from the auxiliary thread and various TCP pipes or named
local pipes.

The central thread will be the main thread. We could move
communication to a separate thread but I doubt it would bring any
advantage. I expect the main thread to poll every hundred thousand
instructions (*) to see if a new byte arrived, so external tools can
pause or control simulation while cores are executing.

On Linux there will be select() in main thread which will on file
descriptors from GDB and various TCP pipes or named local pipes.
Instead of select() we could use poll() or some other variant, but I
am not exactly familiar with them and probable they do not have an
advantage in our program.

* Note: Currently our simulation loop polls inputs after each executed
instruction. This is a performance disaster. I will do some
measurements.

-- 
Petr Hluzin