QUERY: w32 sub process implementation

QUERY: w32 sub process implementation

[dhruva]

Hi,
 In the win32 specific implementation, Emacs creates processes in a
thread. Every sub process of has a corresponding thread in emacs. The
thread entry function is reader_thread which reads a char or accepts a
connection and waits till the char is read by the main emacs
thread/read-eval-print loop.
 Using ASYNC read and registering callbacks in wait, I feel we can
completely do away with threads for sub procs. I would like to have
your views before I start making large changes (in my local copy). If
this is not an area of concern, I could concentrate on other portions.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: QUERY: w32 sub process implementation

[Jason Rumney]

dhruva wrote:
> Using ASYNC read and registering callbacks in wait, I feel we can
> completely do away with threads for sub procs.
Wil this work on Windows 95/98/ME? According to the MSDN docs,
asynchronous reads have limited support, and it is not entirely clear
from the documentation whether the way we handle process I/O would be
included or not.

Re: QUERY: w32 sub process implementation

[dhruva]

Hi,

On 8/20/07, Jason Rumney <jasonr@gnu.org> wrote:
> dhruva wrote:
> > Using ASYNC read and registering callbacks in wait, I feel we can
> > completely do away with threads for sub procs.
> Wil this work on Windows 95/98/ME? According to the MSDN docs,

Could we have a new implementation (and decide at configure time) for
the newer versions on windows only. Just for the sake of
compatibility, do we hold back on improving and simplifying? I agree
we need to support older versions of windows OS but IMHO, should also
move forward.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: QUERY: w32 sub process implementation

[Eli Zaretskii]

> Date: Mon, 20 Aug 2007 07:49:44 +0530
> From: dhruva <dhruvakm@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> On 8/20/07, Jason Rumney <jasonr@gnu.org> wrote:
> > dhruva wrote:
> > > Using ASYNC read and registering callbacks in wait, I feel we can
> > > completely do away with threads for sub procs.
> > Wil this work on Windows 95/98/ME? According to the MSDN docs,
> 
> Could we have a new implementation (and decide at configure time) for
> the newer versions on windows only.

Configure-time decisions are not a good idea, since Windows binaries
are habitually copied between machines, and because many users install
a precompiled binary distribution from ftp.gnu.org instead of building
from sources.

So any such decisions must be run-time decisions.

> I agree we need to support older versions of windows OS but IMHO,
> should also move forward.

There are still many users of Windows 9x, and we don't want to drop
their support.  Any move forward should not break Windows 9x.

Re: QUERY: w32 sub process implementation

[Richard Stallman]

There are countries where lots of people use old versions of Windows
because they can copy and install those easily.  So it is useful
maintain the Emacs support for those old versions.

Re: QUERY: w32 sub process implementation

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> There are countries where lots of people use old versions of Windows
> because they can copy and install those easily.  So it is useful
> maintain the Emacs support for those old versions.

I agree that we shouldn't force anyone to upgrade to newer Windoze versions
to run Emacs.

However, the current implementation of sys_select is sub-optimal and
doesn't support all the features of make-network-process (e.g.
non-blocking connects), so fixing the code as suggested would be
really good.

Does W95/98/ME have a working winsock2 implementation?

If so, I suggest someone try to make the changes and test them on W95/98/ME.

If it works -- great.

Otherwise, it should be possible to keep both the old and the new code
(e.g. by making two sys_select_new and sys_select_old functions, and
choose the right one at run-time.)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: QUERY: w32 sub process implementation

[dhruva]

Hi,

On 8/21/07, Kim F. Storm <storm@cua.dk> wrote:
> Otherwise, it should be possible to keep both the old and the new code
> (e.g. by making two sys_select_new and sys_select_old functions, and
> choose the right one at run-time.)

I am planning to just use function pointers (pfn_XXXX). I am sure it
an be handled easily. For now, I will just focus on getting the new
ASYNC implementation working on newer msw and consider porting at a
later point.
Shall I first hack the sys_select and getting rid of threads for sub
processes in the first go?
I will need help in understanding the handling of keyboard and mouse
events (not even sure if sys_select handles them or it is somewhere
else). I can handle all the typical file and IPC related IO but have
no clue regarding UI events.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: QUERY: w32 sub process implementation

[Jason Rumney]

dhruva wrote:
> Shall I first hack the sys_select and getting rid of threads for sub
> processes in the first go?
>   
No. They are separate issues. Cleaning up sys_select can be done without
breaking backwards compatibility with Windows 95 etc, and will fix
outstanding bugs. Getting rid of threads for sub processes does not seem
to bring any benefits to me.

> I will need help in understanding the handling of keyboard and mouse
> events (not even sure if sys_select handles them or it is somewhere
> else).

It doesn't. sys_select emulates the standard C library select function
for subprocesses and sockets. The reason for its existence is that with
winsock 1.1, the system select function only handles sockets.

Re: QUERY: w32 sub process implementation

[Jason Rumney]

Kim F. Storm wrote:
> However, the current implementation of sys_select is sub-optimal and
> doesn't support all the features of make-network-process (e.g.
> non-blocking connects), so fixing the code as suggested would be
> really good.
>
> Does W95/98/ME have a working winsock2 implementation?
>   

Yes. Cleaning up sys_select to use winsock2 and file handles together in
one select statement can be done separately from async IO. Once that is
taken care of, I think the missing features can be added.

Re: QUERY: w32 sub process implementation

[Davis Herring]

> Does W95/98/ME have a working winsock2 implementation?

My own answer to this question the last time it came up is at
http://lists.gnu.org/archive/html/emacs-devel/2006-07/msg00673.html
(Short answer: yes, for our purposes.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: QUERY: w32 sub process implementation

[Richard Stallman]

    Otherwise, it should be possible to keep both the old and the new code
    (e.g. by making two sys_select_new and sys_select_old functions, and
    choose the right one at run-time.)

I agree that would be ok, assuming that there is no difficulty
with compiling both solutions on all the Windows versions.

Re: QUERY: w32 sub process implementation

[Kim F. Storm]

dhruva <dhruvakm@gmail.com> writes:

> Hi,
>  In the win32 specific implementation, Emacs creates processes in a
> thread. Every sub process of has a corresponding thread in emacs. The
> thread entry function is reader_thread which reads a char or accepts a
> connection and waits till the char is read by the main emacs
> thread/read-eval-print loop.
>  Using ASYNC read and registering callbacks in wait, I feel we can
> completely do away with threads for sub procs. I would like to have
> your views before I start making large changes (in my local copy). If
> this is not an area of concern, I could concentrate on other portions.

I have had the same idea myself, but didn't pursue it due to the "imminent"
release of 22.1.

It would make the w32 sys_select work much more like the "standard"
select - and at the same time make it handle the write mask (to get
rid of the BROKEN_NON_BLOCKING_CONNECT define in ms-w32.h).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk