Re: understanding (task)
On Fri, Mar 25, 2011 at 9:22 PM, Alexander Burger 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', or when >> > the event handler processing '*Run' passes the closed file descriptor to >> > select(2). >> >> what's the reason for running it via (task) in the first place? > > A task is a piece of code to be run whenever a certain "event" happens. > > An "event" is either the expiry of a timer, or the arrival of data on a > file descriptor. There may be several timers and many file descriptors > where the process is expecting something to happen, so they are all put > into a list in '*Run', and handled with I/O Multiplexing (the POSIX > select(2) system call). there you go. thank you. > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
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 to > > select(2). > > what's the reason for running it via (task) in the first place? A task is a piece of code to be run whenever a certain "event" happens. An "event" is either the expiry of a timer, or the arrival of data on a file descriptor. There may be several timers and many file descriptors where the process is expecting something to happen, so they are all put into a list in '*Run', and handled with I/O Multiplexing (the POSIX select(2) system call). Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: understanding (task)
Hi Alex On Fri, Mar 25, 2011 at 4:46 PM, Alexander Burger 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 processes? figured S is >> just a socket and calling (close) in a non forking server would be ok? > > It doesn't matter whether there are multiple picolisp processes: Both > the open file descriptor, and the list of tasks in '*Run', are private > to each process. i see. in this light, i might have been asking the wrong question... > > 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 to > select(2). what's the reason for running it via (task) in the first place? /e -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
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 ok? It doesn't matter whether there are multiple picolisp processes: Both the open file descriptor, and the list of tasks in '*Run', are private to each process. 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 to select(2). Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: understanding (task)
Hi Alex, On Fri, Mar 25, 2011 at 4:00 PM, Alexander Burger 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, > 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 ok? thank you. /e > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=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 (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, and (task S) to remove the corresponding entry from the list in '*Run'. Cheers, - Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
