FreeGLUT keyboard IO timing and synchronization

Using FreeGLut's keyboard callbacks,

glutKeyboardFunc(); glutKeyboardUpFunc(); glutSpecialFunc(); glutSpecialUpFunc(); 

When in the glutMainLoop pipeline do these functions get called? In other systems (C# + OpenTK, XNA, etc.) , I'd use a polled (vs interrupt-driven) approach to perform keyboard IO. That is, in the Update phase of the game loop, I'd do the following:

• update currentKeyboardState via an OpenTK, etc. framework call that returns an array with the state (up, down) of each key

• Iterate through a map of keys, transition states (pressed, held, and released), and associated event handlers

• Where a key transition has occurred that has an attached event handler (determined by comparing currentKeyboardState[key] with previousKeyboardState[key]), call it.

• when all handlers have been processed, copy currentKeyboardState to previousKeyboardState.

In this case, there's no place or requirement for the GLut keyboard functions. However, it appears I have to do things differently in C++. I can, but I'm unsure of when the callbacks registered with GLut are actually called. Are these issued at the beginning/end of the main loop (activated through glutEnterMainLoop(), or are they arbitrarily called, interrupting the main loop no matter it's current state?

If the latter is the case, it seems that I'd need to add a new keyboard state collection, giving

• previousKeyboardState(), the state of the keyboard at the end of the previous loop
• currentKeyboardState(), the state of the keyboard at the beginning of the current loop
• nextKeyboardState(), collection modified by the glutKeyboard*() and glutSpecial*() callbacks, and copied/moved into currentKeyboardState() before the Update phase begins.

Or, I could:

1. Create a std::queue<pair<int,bool>>, where ::first is the key code from one of the keyboard callbacks, and ::second indicates if it is an "up" or "down" event.

2. In the GLut callbacks, add events to this queue. (This may be better implemented as a map to avoid duplicate events for each key, again depending on when and how these callbacks are activated)

3. At the beginning of the update phase, I would use the queue contents to update the keyboard state arrays.

   Of course, this doesn't really solve the problem if a keyboard callback is activated while I'm processing the queue. There are ways around that, also, but this is starting to become really hairy.

The Question

Do I need to be concerned about GLut keyboard callbacks happening during the main loop, or are they guaranteed to only be called between loop iterations (from the point of view of my application)? If the former, what are best practice for dealing with this?

Also, are these callbacks executed in the same thread as the main loop? Should I worry about concurrency issues not only on Windows, but OSX and Linux?

Edit

I've replaced freeGLut with GLFW, which works a bit more like I'd expect. I'd still like some insight on this, though.