understanding (task)

Hi list, in http.l, i see a lot of (task (close S)) usage. from the docs, (task) says it's a front end to the *Run global and created a (job) environment. isn't (close) simple enough to just let it rip? why should it be enclosed in a (task). /e -- UNSUBSCRIBE:

Re: understanding (task)

Hi Edwin, in http.l, i see a lot of (task (close S)) usage. from the docs, (task) says it's a front end to the *Run global and created a (job) environment. That's right. isn't (close) simple enough to just let it rip? why should it be enclosed in a (task). Instead of enclosing it in

Re: understanding (task)

Hi Alex, On Fri, Mar 25, 2011 at 4:00 PM, Alexander Burger a...@software-lab.de wrote: Instead of enclosing it in (task (close S)), two separate calls (close S) and (task S) would also be all right (just a little bigger). But both are necessary: (close S) to free the socket file descriptor,

Re: understanding (task)

Hi Edwin, But both are necessary: (close S) to free the socket file descriptor, and (task S) to remove the corresponding entry from the list in '*Run'. is this in the context of multiple picolisp processes? figured S is just a socket and calling (close) in a non forking server would be

Re: Inferior processes and access to foreign libraries

I believe FFI or Foreign function interface is a term previously used for this, at least in the lisp world. http://en.wikipedia.org/wiki/Foreign_function_interface http://en.wikipedia.org/wiki/Foreign_function_interface/meingbg On Thu, Mar 24, 2011 at 4:21 PM, Alexander Burger

Re: understanding (task)

Hi Alex On Fri, Mar 25, 2011 at 4:46 PM, Alexander Burger a...@software-lab.de wrote: Hi Edwin, But both are necessary: (close S) to free the socket file descriptor, and (task S) to remove the corresponding entry from the list in '*Run'. is this in the context of multiple picolisp

Re: understanding (task)

Hi Edwin, So if you just close the file descriptor, but don't remove it from the task list, you'll get a Key conflict error when the next time a new socket with that file descriptor number is assigned a 'task', or when the event handler processing '*Run' passes the closed file descriptor

Re: understanding (task)

On Fri, Mar 25, 2011 at 9:22 PM, Alexander Burger a...@software-lab.de wrote: Hi Edwin, So if you just close the file descriptor, but don't remove it from the task list, you'll get a Key conflict error when the next time a new socket with that file descriptor number is assigned a 'task',