Re: TIP #175: Add an -async Option to [open]
From: Wojciech Kocjan (hceicjow.backward_at_kocjan.org)
Date: 03/30/04
- Next message: Jeannot: "Re: Link windows to another toplevel"
- Previous message: Daniel A. Steffen: "Re: MacOS Classic support (finally) gone from CVS *sigh*"
- In reply to: Neil Madden: "TIP #175: Add an -async Option to [open]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 30 Mar 2004 08:10:01 +0200
Neil Madden wrote:
> TIP #175: ADD AN -ASYNC OPTION TO [OPEN]
> ==========================================
> Version: $Revision: 1.1 $
> Author: Neil Madden <nem_at_cs.nott.ac.uk>
> State: Draft
> Type: Project
> Tcl-Version: 9.0
> Vote: Pending
> Created: Monday, 15 March 2004
> URL: http://purl.org/tcl/tip/175.html
> WebEdit: http://purl.org/tcl/tip/edit/175
> Post-History:
>
> -------------------------------------------------------------------------
>
> ABSTRACT
> ==========
>
> This TIP propose to add an *-async* option to the [open] command, with
> identical semantics to the *-async* option to the [socket] command.
>
> RATIONALE
> ===========
>
> With the introduction of Virtual File Systems (VFS, see [TIP #17]), it
> is now possible to use [open] to access resources which are not
> available in the local file system. However, initial access to these
> resources may take some time (for instance, in an HTTP VFS, this
> requires an HTTP GET request to a remote server). Currently, while this
> request is being processed, the Tcl application will block waiting for
> a response. It may take several seconds before the open call returns,
> and control is passed back to the application. Delays of this length
> can cause problems, especially in applications with a Tk graphical user
> interface, which will not repond to events until the call has
> completed. Tcl provides mechanisms to avoid this initial blocking for
> the socket command, and in the HTTP package. However, this
> functionality is missing from the open command. For VFS to become
> useful for writing network code, this functionality needs to be added.
> [cut]
Wouldn't it be much simplier if the VFS layer would use fileevents and
always open in async mode? For example if you want to download/upload a
file, do open, wait for it to become readable/writable and then
read/write. In this case you wouldn't get any blocking. Otherwise (if
you try to do some IO just after opening), you'll block in this case -
of course this would mean a rewrite of most networked tclvfs modules.
This could also mean adding more options to rechan - I'm not sure if
things like blocking/non-blocking and fileevents can be implemented.
Also, note that [open -async] would make a lot of people misunderstand
the idea - for example on most (or all?) OSes it would not mean async
opening of networked mounts (like SMB on Windows) or opening a file on
floppy drive...
The way I see it is that you do:
# this does not try to download anything yet
set fh [open http://www.somedomain.com/somefile.zip r]
fconfigure $fh -translation binary -blocking 0
# now, wait for the download
proc doRead {fh} {append ::data [read $fh]; if {[eof $fh]} {...}}
fileevent $fh readable [list doRead $fh]
-- WK
- Next message: Jeannot: "Re: Link windows to another toplevel"
- Previous message: Daniel A. Steffen: "Re: MacOS Classic support (finally) gone from CVS *sigh*"
- In reply to: Neil Madden: "TIP #175: Add an -async Option to [open]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
