[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-dev
Subject:    RE: Using threading to remove blocking
From:       Philippe FREMY <P.FREMY () OBERTHURCS ! com>
Date:       2002-11-14 12:05:55
[Download RAW message or body]


> Vim has got an internal queue where keypresses
> (and other events which are treated as user input, like
> mouse clicks) are stored. At the moment, if the
> queue is empty it spins, despatching incoming GUI
> messages in the meantime. However this is not allowable
> behaviour for an in-process component.
> 

> Vim works in a slightly different way, so that
> it can keep as much common code with non-event
> driven frameworks (console versions) as possible:
> -----------------------------------------
> Vim:
> 
> mainloop()
> {
> 	while (1)
> 	{
> 		if there are queued keys
> 			action them;
> 		else
> 			wait_for_key();
> 	}
> }

Actually, it is more.

> mainloop()
> {
> 	while (1)
> 	{
> 		if there are queued keys
> 			action_key( key );
> 		else
> 			wait_for_key();
> 	}
> }

With many action them spread inside the code:

action_key( key )
{
	switch(key) {

	case something:
		[...]
		if (need_more_keys()) wait_for_keys()
		[...]

	case some other thing:
		[...]
		if (need_more_keys()) wait_for_keys()
		[...]
	}
}

This is why you can not act on the action_key part of the code. Too many of
them.

Despite what I said here, I am seriously considering the threading solution
for our component. I need to look more closely at the code. I think it is
trickier than the simple scheme described by Vince. If I have a vim thread
and a GUI thread, I must forward gui events to the vim thread, which will
react with gui actions that may have to be performed by the GUI thread. So
critical sections must be added carefully.

This is the closest to the solution we have. I don't like it because it
makes the whole thing very complicated. It is very easy to overlook one case
that does not happen very often but where you end-up with an infinite loop.

> Obviously the actual implementation might need
> a few more critical sections added here and there,
> but I hope you can see that this build variant
> could be accommodated inside the main code tree
> without disrupting existing builds, or having to
> turn Vim inside out.

Do you think it could make it inside the core of vim ? I think this is
really gui or component specific and it is up to each gui/component
implementer to deal with it.

	regards,

	PHilippe
###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.F-Secure.com/
[prev in list] [next in list] [prev in thread] [next in thread]