Re: non-blocking sockets (was Re: Are there plans for a multi-threaded Emacs?)

[storm@cua.dk (Kim F. Storm)]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> 
> > Hmmm... maybe if most of the threading issues are with socket
> > communication then better sentinels would be a good idea. Maybe a
> > callback API for setting up and reading/writing to sockets would
> > really useful. Such an API would be a doddle to write of course.
> 
> Doh!
> 
> Elisp 21 already has non-blocking sockets... I don't remember them
> from the last time I did any socket stuff but they are there.

Yes I know (I added it :-).

Problem is that often people whine about the things that are missing,
rather than trying to use the things that are already there.

> 
> So one big win would be to convert as much network reliant code to
> using non-blocking sockets which someone already said.
> 
Indeed!

Sending and receiving mail could definitely run "in the background"
using non-blocking i/o.

> 
> Since 'open-network-stream-nowait' returns nil when it's not
> supported it seems fairly safe to add it to all networking
> code. Maybe a new form is needed:
> 
>    open-network-stream-nowait-if-possible
> 
> which does an nbio connection if it can but otherwise a normal one.
> 

I considered this when I created the interface (the low-level function
is make-network-process), but I found that there is no general way in
which you could use either nbio or bio with the same sentinels and
filters, as the sequence of events is different.  

IMO it is better not to make an open-network-stream-nowait-if-possible
which pretends it is simpler than it really is!  Using nbio _is_ a
little more tricky that blocking io.

> 
> If your system doesn't support nbio then you'll still have to wait
> for Emacs threads for faster network connections   /8->
> 

Personally, I wouldn't care about such systems.

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