Re: understanding (task)

[Edwin Eyan Moragas]

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)

[Alexander Burger]

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)

[Edwin Eyan Moragas]

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: Inferior processes and access to foreign libraries

[Alexander Burger]

Hi meingbg,

> I believe FFI or "Foreign function interface" is a term previously used for
> this, at least in the lisp world.

Yes, I was aware of that.

However, the described mechanisms cover more than just function
interfaces, like calling external sub-processes or sockets and other IPC
protocols.

Cheers,
- Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Inferior processes and access to foreign libraries

[meingbg]

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

/meingbg

On Thu, Mar 24, 2011 at 4:21 PM, Alexander Burger wrote:

> Hi Jon,
>
> > This overview of the different ways of integration with other
> > software is very good! It deserves a place in the wiki. ;-)
>
> Good idea!
>
> I'm still not sure, however, if it is complete. I'm getting a bit
> confused about that, it is the only place where pil32 and pil64 are
> substantially different.
>
> What might be a proper title? "Foreign Code Integration"?
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: understanding (task)

[Alexander Burger]

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)

[Edwin Eyan Moragas]

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)

[Alexander Burger]

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

understanding (task)

[Edwin Eyan Moragas]

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: mailto:picolisp@software-lab.de?subject=Unsubscribe