Im new to callbacks, I am trying to make an input buffer with a callback
so that i wont miss out inputs while doing lazy processing..

this is what i came up with

Then in main:

but after buf.end reaches 255 the program gets stuck.
The same program works perfect if i make everything in 'input' structure as separate
global variables.

There are No compile Errors

I compile with -lalleg -O -Wall in Dev-C++
Can Someone help

Sheesh !! what a silly mistake. I was rather mislead by the complexity
of callbacks into thinking that there was no problem with the code.

thanx a lot.

I was also a bit skeptic about the implementation. Are there any other
better ways to implement such a thing.

I don't know. In my Allegro callbacks, I do not bother locking (A: I think it only matters on DOS, and B: I think it only matters when there is a performance anomaly).

Hm, yeah, buf.end++ should probably be moved to after the buffer entry becomes valid instead of before, or you have a race condition there. In the example code the race won't actually do anything except cause the wrong values to be displayed once in a while, but for a real-world program that could be a serious issue.

The current system "gives up" (return and discard the event) when mouse_call() and key_call() race each other.

I'd replace the whole "lock" system by a mutex to cover all operations on start and end. The locking and unlocking are only one function call, and when you use the "official" mutex functions it's much easier to verify, from reading the code, that the critical section is indeed protected.

Just to make sure we're on the same page here (because it looks to me like we might, possibly, be talking about different things):
What I think axilmar was talking about, and certainly what I was attempting to agree with, is changing this:

   buf.end++; //Quickly copy stuff
   buf.queue<i>.type = 0;
   buf.queue<i>.val = f;
   buf.queue<i>.ex1 = ex1;
   buf.queue<i>.ex2 = ex2;
   buf.queue<i>.ex3 = ex3;

to this:

   buf.queue<i>.type = 0;//Quickly copy stuff
   buf.queue<i>.val = f;
   buf.queue<i>.ex1 = ex1;
   buf.queue<i>.ex2 = ex2;
   buf.queue<i>.ex3 = ex3;
   buf.end++;

The idea here being that if buf.end is incremented before buf.queue is updated, then your main loop will notice that buf.end is no longer equal to buf.start, and read out the values of buf.queue, at a time when they may or may not be initialized. By making that change, the main loop isn't told about the new mouse event until it's guaranteed to be able to correctly read buf.queue. This is known as a race condition; it is a real possibility on windows, though maybe not on DOS. It would probably be extremely rare, at least on single-core CPUs (the OS scheduler would have to preempt mouse_call after buf.end++ and before buf.lock--).

Anyway, onward:

I'm not familiar with CGUI, but I am familiar with SDL, which uses an input buffer (patterned after win32 & DirectX I think, though I haven't done much win32 and/or directX programming). It is my opinion that input buffers are superior to the polling interface that Allegro offers for large programs, but inferior for small programs. My current program extends the concept slightly... it timestamps all input, considers time to be an input, and logs all input to file, in order to allow exact program execution to be reproduced, and as a cheap (read: not very good) way to have game mechanics still feel correct when rendering is slow.

What's wrong with your current code? It appears to buffer mouse events fine. The keyboard code isn't posted, but I presume it buffers those okay also. What are you asking for beyond general commentary on the concept of input buffers in general and/or the specific implementation in CGUI?

The only severe problem was the array[256], fixed.

Your test code to show the internals is not thread safe, but it will only cause a problem when the buffer is getting full and the buffer's head starts biting its tail.
(It should behave like: "lock, make a copy of the element, remove the element, unlock" : afterwards, you have all the time you want to process the event)
IMO, don't bother. Increase the buffer to 512, 1024 or even more if you actually run into problems. (full buffer means missed events, anyway)

The problem I pointed should not happen often, but consequences on input should be VERY weird:
Missed event: if it's a key_up, key_down, or mouse butto, it will look like a stuck key.
It will also cause an earlier entry in the buffer to be considered new, and happen again. It will be very visible as the mouse will jerk away and come back, or a key you didn't press will happen to be stuck down.

In my example I took the mutex functions that are in the pthread library, but it doesn't mean you need to multi-thread - the allegro hooks should work fine.

Yes, Allegro uses threads internally.
Why dedicate threads yourself if the API already does things right? (and dialmformartian uses it rather correctly)
My first hint was only to use to a reliable and standard mutex system : two functions, lock and unlock. Just surround the critical sections, the closer the better.

On further thought:

1. Threading/locking/mutexes/whatever:

So far as I can tell, the keyboard/mouse callbacks in Allegro are all executed from a single thread. Thus, there is no benefit to adding mutexes or anything like that.

Thus: don't use pthreads/whatever for this. Use of platform-dependant or other-library-specific threading primitives is unnecessary and undesirable in this context. Even the "lock" variable in the code is useless. The only kind of thead-awareness needed is the the stuff alread there - the "volatile" keyword on the buffer variables and careful ordering of when buf.end and buf.start are incremented.

2. mouse_call:

dailmformation:
You're implementation is perfectly fine as is. Here are a few things I would consider doing anyway, just because I think the resulting code easier to read or maintain or prettier or something.
2a: eliminate the branches and temporary variables - they don't accomplish anything.
this:

   unsigned int i, ex1 = 0, ex2 = 0, ex3 = 0;
  
   if(f & MOUSE_FLAG_MOVE) {
      ex1 = mouse_x;
      ex2= mouse_y;
   }
   if(f & MOUSE_FLAG_MOVE_Z)
      ex3 = mouse_z;

becomes this:
unsigned int i;
and this:

   buf.queue<i>.ex1 = ex1;
   buf.queue<i>.ex2 = ex2;
   buf.queue<i>.ex3 = ex3;

becomes this:

   buf.queue<i>.ex1 = mouse_x;
   buf.queue<i>.ex2 = mouse_y;
   buf.queue<i>.ex3 = mouse_z;

2b. Make the size of the buf.queue array be a numerical constant (an enum or #define) instead of hardwired. Do the same thing for the "type" values (currently 0 is mouse, 1 is keyboard - wrap those values in enums or #defined constants instead). That way it's easier to change the values later if there is some need to do so.
2c. So far as I can tell, there is no point to the use of buf.lock on windows (or, I suspect, any other Allegro platform). You could remove it.

3. Buffered Input:

dialmformartian: Your main loop reading the callbacks looks correct. I would suggest that that the next step be to add an interface/wrapper to hide/encapsulate the details of the buffer from the main loop or anything else that needs to read keyboard/mouse events.

But that thread is a different one from the main thread. Adding a mutex would prevent synchronization problems between the main thread and the allegro input thread.

Actually, it is not. There is a possibility that non valid data will be read from the buffer.

No they are not atomic. A variable increment has 3 CPU instructions: a) load value to register, b) increase value, c) put value back to memory.

For example:

int x = 0;
x++;

becomes:

004113B5  mov         eax,dword ptr [x] 
004113B8  add         eax,1 
004113BB  mov         dword ptr [x],eax

(copied from the disassembly window of the VS debugger).

But the whole point is to make the whole thing deterministically safe. It's not a big deal to include pthreads in your source anyway.

where do i get pthread

Sigh.
Okay, let's this from three angles:
1. Would adding a pthreads lock to the callback change anything on any specific platform?
2. Is this the manner in which Allegro intends its callbacks to be used?
3. What is the cost of adding additional locking?

Now, the answers for each question:
1. Would adding a pthreads lock to the callbacks change anything on any specific platform?
In order for it to change something, the callback functions would have to be running concurrently with themselves on some platform. This never happens on DOS, Windows, or Linux, the 3 platforms mentioned so far in this forum thread.
DOS: the callbacks appears to happen from within an interrupt - ie with interrupts disabled so they cannot be interrupted.
WIN32: the callbacks appear to be called from a single thread which does nothing but wait for input and call the callbacks when input arrives. Since this is a single thread, it can't call another callback until the previous one returns.
LINUX: the callbacks appear to occur inside the SIGIO handler. According to the GNU docs, no signal handler is called during handling of the same signal, and since both keyboard and mouse use the same signal, neither keyboard nor mouse callbacks can run concurrently with themselves or each other.

2. Is this the manner in which Allegro intends its callbacks to be used?
Allegro documentation says that the keyboard callback "executes in an interrupt context". It doesn't say that as DOS-specific, though obviously it's not literally true for non-DOS platforms. For the mouse callback, all it says is "function must be in locked memory, and must execute very quickly", even less helpful. My interpretation is that this is the correct way to use the Allegro callbacks, though the documentation leaves this unfortunately ambiguous.

3. What is the cost of adding additional locking?
If you use Allegro's built-in locking mechanisms (_enter_critical() and _exit_critical())... well, I don't know what the drawbacks are - Allegro's built-in locking mechanisms are undocumented so far as I can tell, so I presume you're not intended to use them for normal Allegro programs.
If you use platform-specific locking mechanisms, the obvious cost is in portability.
If you use pthreads or another threading API with implementations for a variety of platforms, the obvious cost is the standard cost for adding dependancies - it makes it harder for arbitrary Allegro users to get your code running - they have to get the library themselves, and figure out how to install it and link with it. This cost is greatly reduced if you are the only one likely to compile your code. (additionally, I suspect that using pthreads calls inside a DOS interrupt is a bad idea)

edit: note: this is only considering adding locking to the callback. I would recommend adding locking to any function that reads from the input buffer if and only if your code is multithreaded independent of Allegro.