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
>
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 de
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? figur
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
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
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