[erlang-questions] jinterface

Robert Virding rvirding@REDACTED
Wed Oct 8 15:57:14 CEST 2008

Yes, it is easy to get around this, but no it is not. The io module was
designed to send the formatting computations to the io-server to be done
there. The group leader is an io-server as well as being group leader (see
my Erlang Rationale for a bit better explanation). As I see it you have the
following options:

- Do not use io:fwrite or other formatting io calls directly but instead do
io:put_chars(io_lib:fwrite(Fmt, Args)) instead. This ensures that only an
iolist is sent to the group leader.
- Modify io.erl to do this for automatically for you and use this private
version. This is not difficult and should cause no other problems.
- Modify your program so that you start a local group leader/io-server which
does the formatting and just send the output iolists to the otp.net process.

Do you do any input from otp.net? If so you will have to do the last option
and fix the otp.net process a bit.

I hope this helps,


2008/10/8 Serge Aleynikov <saleyn@REDACTED>

> Last weekend I did implement support for monitoring Erlang pids in otp.net.
>  It seems to work ok, though I see Vlad's point in that it's somewhat
> cumbersome to use Erlang-style message passing in a language that doesn't
> support native concurrency.
> I faced another "challenge" being that the IO requests in the form of
> io:format(Fmt, Args) get directed to a group leader in the otp.net node as
> an io_request carrying some {put_chars, io_lib, format, Args} content.  The
> inconvenience is that otp.net node doesn't have any clue of how apply that
> io:format/2 function to format that output.  Is there a way to force the
> evaluation to happen on the Erlang side so that it would come to the
> non-Erlang node as {put_chars, String} of some sort?
> Serge
> Robert Virding wrote:
>> That would be a better solution in the long-run, but it is one which,
>> unfortunately, I can't help you with.
>> Robert
>> 2008/10/4 Serge Aleynikov <saleyn@REDACTED>
>>  Ah, I see, this makes sense.  Meanwhile, I looked through the
>>> distribution
>>> sources, ei, and jinterface and see that it's not that difficult to add
>>> some
>>> monitoring support for non-Erlang nodes so that they can monitor Erlang
>>> pids.  I'll patch otp.net and later ei if I find time this or next
>>> weekend.
>>> Serge
>>> Robert Virding wrote:
>>>  It's not the io server which tries to setup a monitor, but the io module
>>>> itself. These are two separate but cooperating entities. The io module
>>>> monitors the io server to make sure that the call will not block if the
>>>> process dies. The easiest way around this is to do the send/receive to
>>>> the
>>>> io serv yourself without a monitor.
>>>> Robert
>>>> 2008/10/4 Serge Aleynikov <saleyn@REDACTED>
>>>>  One other "nasty" feature is that any attempt to make an RPC call of
>>>>> io:format/2 from a Java/.NET node fails with badarg, because io server
>>>>> tries to set up a monitor to the remote pid and fails miserably...
>>>>> Actually I see what's missing in Java/OTP.NET implementation.  These
>>>>> features are documented here:
>>>>> http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html#9.7
>>>>> Serge
>>>>> Paul Guyot wrote:
>>>>>  Date: Sat, 04 Oct 2008 01:32:55 -0400
>>>>>>> From: Serge Aleynikov <saleyn@REDACTED>
>>>>>>> Subject: Re: [erlang-questions] jinterface (was: otp.net)
>>>>>>> I tried a similar test using jinterface to see if it's possible to
>>>>>>> monitor processes running on a Java node and ran into the same
>>>>>>> failure.
>>>>>>> Can anyone explain what's wrong?
>>>>>>> (server@REDACTED)10> {test, client@REDACTED} ! {self(), hello}.
>>>>>>> {<0.45.0>,hello}
>>>>>>> (server@REDACTED)11> f(), {Pid, _} = receive M -> M end.
>>>>>>> {<5979.1.0>,hello}
>>>>>>> (server@REDACTED)12> erlang:monitor(process, Pid).
>>>>>>> ** exception error: bad argument
>>>>>>>     in function  erlang:monitor/2
>>>>>>>        called as erlang:monitor(process,<5979.1.0>)
>>>>>>>  I've seen a comment in stdlib/gen.erl, at line 196, that suggests
>>>>>> that
>>>>>> Java and C nodes are featureweak, and processes in such nodes cannot
>>>>>> be
>>>>>> monitored. Instead, you have to monitor the whole node with
>>>>>> monitor_node/2. This makes sense because the OTP ei (C library) or
>>>>>> jinterface do not monitor "processes". Indeed, there is only one pid
>>>>>> per
>>>>>> node, which is the node's pseudo-pid (even if technically, each
>>>>>> connection can receive messages). I guess you can draw from the code
>>>>>> in
>>>>>> gen.erl if you need to monitor either an erlang process or your java
>>>>>> process, or just monitor the node if you only need to monitor java
>>>>>> processes.
>>>>>> Regards,
>>>>>> Paul
>>>>>>  _______________________________________________
>>>>> erlang-questions mailing list
>>>>> erlang-questions@REDACTED
>>>>> http://www.erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081008/2f81deb1/attachment.htm>

More information about the erlang-questions mailing list