Re: Asynchronous DNS

[Alain Schneble]

Lars Ingebrigtsen <address@hidden> writes:

> Alain Schneble <address@hidden> writes:
>
>> I think the point here is that with these blocking calls in place, we
>> wouldn't really need a separate :nowait 'immediate, just the existing
>> :nowait t.  And IIUC, this is also what Eli Zaretskii proposes.  With
>> this model, :nowait t really means: I request as much async behavior as
>> possible.  But if code is not arranged in an async fashion, then well,
>> you might not get full async behavior.  It's your fault, but we won't
>> signal an error.
>
> If we can identify all the places where we have to insert these
> blockers, then having :nowait t be as async as possible, then that would
> be nice.  I kinda feel that might not be realistic.  But I may be
> wrong.  I mean, there aren't a hundred process-related built-in
> functions...  Your list was just in the tens, right?

I think it should be feasible, really.  The ones I had identified were
these (oh, I think I just looked in process.c, but that should be
sufficient, right?):

`process-contact', `set-process-filter', `set-process-filter-multibyte',
`set-process-window-size', `set-network-process-option',
`set-process-coding-system', `process-filter-multibyte-p',
`process-datagram-address', `set-process-datagram-address',
`process-send-region', `process-send-string', `process-send-eof'

Maybe the last three wouldn't be candidates as they throw an error even
in the current implementation in case the process status is still
'connect, as you and I pointed out already in earlier notes.